Re: Conversion functions.

[Magnus Myrefors <myrefors magnus telia com>]

I tried with strtod() but it only worked with strings with no
decimal-point, otherwise the resulting double was truncated.
I also tried to copy g_ascii_strtod() (from glib-2.12-9) into 
my code but it didn't compile and I didn't quite understand
the if-statement if(decimal_point_pos) {} where decimal_point_pos 
was declared as const char *decimal_point_pos.
I thought that a pointer was an address in memory and I haven't
seen a pointer in a if-statement like that before.
I guess I have to write my own conversion-function.

Magnus      

On Tue, 4 Sep 2007 20:55:45 +0200
David Nečas (Yeti) <yeti physics muni cz> wrote:

> On Tue, Sep 04, 2007 at 04:18:23PM +0200, Magnus Myrefors wrote:
> > 
> > I tested my code with valgrind and I got some error-messages
> > that derived from my own code.I changed the code and then
> > the error-messages disapperad. I still get wrong values that 
> > seem to occur randomly though... 
> >   Below is the output from valgrind. It is the end of the
> > error-messages that were generated when the program is reading 
> > the text-file and use g_ascii_strtod().
> 
> Errors like
> 
> > ==3782== Conditional jump or move depends on uninitialised value(s)
> > ==3782==    at 0x467A1F6: g_unichar_isspace (guniprop.c:275)
> > ==3782==    by 0x446C1BE: pango_default_break
> > (in /usr/lib/libpango-1.0.so.0.1400.8)
> > ==3782==    by 0x446D2B0: pango_break
> > (in /usr/lib/libpango-1.0.so.0.1400.8)
> > ==3782==    by 0x447D7E2: (within /usr/lib/libpango-1.0.so.0.1400.8)
> > ==3782==    by 0x447E26A: (within /usr/lib/libpango-1.0.so.0.1400.8)
> > ==3782==    by 0x447F282: pango_layout_get_pixel_extents
> > (in /usr/lib/libpango-1.0.so.0.1400.8)
> > ==3782==    by 0x40AB99E: get_size (gtkcellrenderertext.c:1522)
> > ==3782==    by 0x40A6053: gtk_cell_renderer_get_size
> > (gtkcellrenderer.c:536)
> > ==3782==    by 0x4246DA6: gtk_tree_view_column_cell_get_size
> > (gtktreeviewcolumn.c:2606)
> > ==3782==    by 0x422E52D: validate_row (gtktreeview.c:4693)
> > ==3782==    by 0x4232388: do_validate_rows (gtktreeview.c:5255)
> > ==3782==    by 0x4239F8B: gtk_tree_view_size_request
> > (gtktreeview.c:1822)
> 
> are printed long after the data is loaded I suppose.  They
> can mean crap stored in the tree model, or perhaps they are
> harmless (normally I do not see treeviews produce these).
> 
> In any case they do not say anything about the conversion
> problem (they say the test program is probably not very
> minimal though).  If no *different* errors are printed
> first, then we have not found anything.
> 
> Simple things that can be tried next:
> - if the numbers are normal, i.e. supported by underlying
>   strtod(), try to use it directly -- be careful with the
>   locale in this case
> - copy g_ascii_strtod() from the latest glib/strfuncs.c,
>   paste to your code and use this copy to see whether it
>   makes any difference
> 
> Still, the randomness indicates a nasty bug in your program.
> I suppose if you make a minimal program that just reads the
> data, the problem goes away.
> 
> Yeti
> 
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list