Re: printf("%.0f", 0.5) and round-to-even

[Eric Blake]

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