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

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

Allin Cottrell wrote:

> On Tue, 13 Aug 2002, Eric M. Monsler wrote:
>
>
> > I feel it should not crash on any input.
> >
> > I have a similar test case, which uses:
> >
> > tmp_float = (float)strtod("6.0e-44",NULL);
> > g_string_sprintf(pGStr,"%6.2f\n",tmp_float);
> >
> > and produces the same crash.
>
> I'd say that crashing is an acceptable response.  It's up to the
> programmer to ensure that such functions are fed with input that is
> within bounds.  In the example above, inspecting errno would have
> shown that tmp_float did not have an acceptable value.  I suppose one
> could say that it's a "quality of implementation" issue, and that a
> "nice" library will try to work around invalid input so far as
> possible.  But I wouldn't describe the crash as a bug, any more than
> it's a bug when fprintf() segfaults when fed a null FILE
> pointer.



Inspecting errno when?  After the cast from double to float?  Because 
control does not return to the program after the g_string_sprintf() 
call, as the negative malloc causes a GLib error.  Hence my description 
of the problem as a "crash" rather than "failure" or "incorrect output".

Try generating any other float of magnitude e-40 to e-43, and see the 
same result.  I just tried f_val = 6.2e-21, f_val *= 1.0e-21, and saw 
the same error and crash.  I did not check errno after the multiplication.

Therefore, if you define the current 1.2.x behavior to be correct, I the 
developer must manually check the float range of every value before 
calling g_string_sprintf().

Did you write the routine in 1.2.x that computes how many bytes the 
string may need?  If so, I very much appreciate your effort and 
contribution, but respectfully point out that you had a bug.


Eric