Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
- From: Sven Neumann <sven gimp org>
- To: "Eric M. Monsler" <emonsler beamreachnetworks com>
- Cc: gtk-app-devel-list <gtk-app-devel-list gnome org>, "gtk-list gnome org" <gtk-list gnome org>, Christopher Keller <CKeller BeamReachNetworks com>
- Subject: Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux
- Date: 12 Aug 2002 23:07:51 +0200
"Eric M. Monsler" <emonsler beamreachnetworks com> writes:
> I'm jumping lists with this; my apologies, but it's definitely a gtk
> bug and so want to followup to gtk-list.
the correct place to report this would probably have been
> If I try to print a denormalized float with a specific format string,
> e.g. "%6.2f\n", using g_string_sprintf(), the program crashes with an
> error about allocating a negative number of bytes.
> An example program is below, showing the error when compiled and run
> under Linux. I believe that the problem is present in both 1.2.9 and
I can reproduce the problem with gtk+-1.2.10 (or actually glib-1.2.10)
running under Linux on an i686:
GLib-ERROR **: could not allocate -6 bytes
> have two questions:
> 1) Is there ongoing bugfix developement on 1.2.x GTK+?
> 2) Is this bug fixed in Gtk+ 2.0.x?
it seems to work better with GTK+-2.0 (or actually glib-2.0):
> > I am seeing a crash, although with GLib error message, when printing
> > a floating point number.
> > The error message is that GLib is unable to allocate -7 bytes.
> > Which seems reasonable enough.
> > The problem is that the data I am trying to print does not seem to
> > be a valid floating point number. My program needs to be
> > crash-proof in this case, as bad data is going to be encountered. I
> > see that the value that is bad is typically something like
> > "6.0245e-44", which is not valid.
> > The fact that I can read the value means that ddd/gdb is handling it
> > properly, but not g_string_sprintf.
> > Any clues? Any suggestions as to how to clamp the floating point
> > value? I have tried to do so with comparisons to MAX_FLT and
> > MIN_FLT, without success.
I don't think you can reliably perform range tests on uninitialized
memory since the compiler knows about the fact that the value was
never initialized and may optimize the range check away.
] [Thread Prev