Eric Blake <ebb9 <at> byu.net> writes:
> > Does glibc do round-to-even here generally (not just in the one special case
> > you mentioned?) If so, the module name should be called fprintf-gnu,
otherwise
> > fprintf-posix-ext.
>
> Both glibc and the gnulib *printf replacement already round to nearest;
> and cygwin 1.5.x failed enough other tests that the gnulib replacement was
> already selected (as evidenced by the fact that on cygwin, gawk and m4 got
> different results, because only m4 uses gnulib's replacements).
In the case of cygwin, this was a true bug, as opposed to an awkward
specification of implementation-definedness. newlib is documented as
attempting round-to-nearest semantics, and does just fine in most scenarios:
printf("%.2f", .125) => 0.12
printf("%.2f", .375) => 0.38
printf("%.0f", 10.5) => 10
printf("%.0f", 11.5) => 12
It was only failing on corner cases where the potential to round affected the
digit immediately before '.', and I've posted a one-liner patch that will
hopefully make it into cygwin 1.7.0:
http://sourceware.org/ml/newlib/2008/msg00499.html
Are there are any other platforms out there where printf("%.1f",.75) rounds
differently then printf("%.2f",.375)? In other words, is it worth testing that
implementation-defined rounding is at least consistent, even if it doesn't
comply with round-to-nearest? (returning .7 and .38 in the above example
points to a bug; a consistent application should return .7 and .37, or .8
and .38).
>
> I suspect %a is also affected, although in newlib's case, %a goes through
> a different code path than %[efg].
newlib's %a was immune.
--
Eric Blake
