On 03/08/2013 10:47 AM, Paul Eggert wrote: > > OK, thanks, it looks like the gnulib test is being too picky: > it's insisting on round-to-even but POSIX says the rounding > is implementation-defined. Mac OS should probably be rounding > to even but that's not our job. I pushed the following patch.
Where do you read that? I see that POSIX says that rounding is implementation-defined for f, F, e, E. Then for a and A, it says: For a and A conversions, if FLT_RADIX is not a power of 2 and the result is not exactly representable in the given precision, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction. But appears to say nothing about the case when FLT_RADIX _is_ a power of 2, yet the result is not exactly representable. Still, by extrapolation, I would assume that we want the error to be in the correct direction for the current rounding, and since both round-to-even and round-to-plus-inf would result in 1.5 becoming 2, not 1, I think this is a bug in Mac OS. But until we fix gnulib to work around Mac's rounding bug, I'm okay with relaxing the test. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
