On Sat, Feb 15, 2003 at 09:02:46PM +0000, Tor Lillqvist wrote:
> It turns out the bug is caused by Trio, the printf/scanf
> implementation included in GLib 2.2, and used on for instance
> Win32. (The main cause to use Trio instead of the C library's
> printf/scanf on some platform is that the C library doesn't have a
> C99-compatible snprintf() or positional printf parameters.)
>
> When script-fu passes for instance the number 14 as a double to gimp,
> wire_write_double() uses g_snprintf("%0.50e") to write it out to the
> pipe as a string. g_snprintf() uses trio, which for some reason
> produces the string
> "1.39999999999999991118215802998747676610946655273438e+01" (and not
> "1.40000000000000000000000000000000000000000000000000e+01", as I
> perhaps naively would have expected).
>
> In GIMP, in wire_read_double(), this string is then converted back
> into a double in with the C library sscanf("%le"), producing
> 13.999999999999998. When this is converted to an integer in
> rect_select_invoker() when calling rect_select(), you get 13.
>
> Sigh. I'll do some more testing and file a detailled bug report on
> GLib/trio. Or is this a bug in GIMP, should it do some tiny amount of
> rounding of the last significant digits in wire_read_double? I am no
> floating point expert, does that make any sense?
>
> Or is the bug in Microsoft's C library? Should scanf()ing the above
> string produce the double 14, and not something a tiny bit less.?
It looks to be trio's fault, there is a bug similar to this opened already:
http://bugzilla.gnome.org/show_bug.cgi?id=101874
Perhaps special case this on windows to use the native snprintf (I assume it
exists there). This isn't an issue in GIMP 1.3, since we don't transmit
doubles as text over the wire anymore.
Probably we should do byte order negotation in the wire protocol at some
point.
-Yosh
