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.?
--tml
