Re: Crashing g_string_sprintf when printing invalid floats. gtk+-1.2.9 on Linux

["Eric M. Monsler" <emonsler beamreachnetworks com>]

All,

I'm jumping lists with this; my apologies, but it's definitely a gtk bug 
and so want to followup to gtk-list.

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 
1.2.10.

If I change the format string to "%g\n", I get an answer that is 
"something e-44", which is why I think that the denormalized is the 
problem.  On Solaris, I get "0.000", which is I believe the correct 
response.

I think that I can work around this with additional testing, but I have 
two questions:
1) Is there ongoing bugfix developement on 1.2.x GTK+?
2) Is this bug fixed in Gtk+ 2.0.x?

Eric Monsler


#include <gtk/gtk.h>
int main (int argc, char *argv[])
{
  GString  *pGStr;

  union {
    int   i_val;
    float f_val;
  } the_data;

  gtk_set_locale();
  gtk_init(&argc,&argv);

  the_data.i_val = 1;
  pGStr = g_string_new("");
  g_string_sprintf(pGStr,"%6.2f\n",the_data.f_val);

  printf(pGStr->str);
}




Eric M. Monsler wrote:

> All,
>
> 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.
>
> As an aside, the problem has never been observed when using the Solaris 
> version of the program, just the Linux one.
>
> Thanks in advance,