[Bug libc/4943] Inconsistent rounding behaviour for sprintf and IEEE doubles

["paul at inet dot co dot za" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From paul at inet dot co dot za  2007-09-20 07:03 -------
(In reply to comment #5)
> (In reply to comment #4)
> > Thank you for making my point for me.  Your exact same code compiled
> > with MinGW for Windows produces the following output:
> 
> This is a different C library under Windows, not the glibc.

The C library used under Windows is, as I have already pointed out, MSVCRT.DLL.
 You will note that my bug report is against glibc.  I am well aware of the
source of the problem.  MinGW links against the standard Microsoft runtime.

> > You still don't spot the inconsistency?
> 
> No inconsistencies. You get different results because the C standard doesn't
> specify these cases and the C libraries are different. FYI, the Mac OS X libc
> and the Solaris2.7 libc both give the same results as glibc. So, if there is a
> library that would need to change in order to make the results the same
> everywhere is MinGW, not the glibc.

I have 20 years in the financial services industry and 25 years in development.
 This little "peculiarity" of glibc has caused us any amount of trouble.  It is
a significant deterrent for us against glibc usage.

Whilst I could believe what you say for Mac OS, as it derives from FreeBSD and
quite likely uses glibc, I would query your statement about Solaris2.7.  Even if
Solaris indeed does exhibit this behaviour, there is still no need to assume
that it is correct behaviour.  One would be better off emulating a library which
 has 90% following in the industry rather than one which sees 5% usage.

> > Rounding toward even numbers is mathematical nonsense.
> 
> You may think that, but this doesn't make a standard. IEEE-754 rules are already
> well-established. So, it would be a bit difficult for you to make things change.

Oh, I don't change is too difficult.  Just taking the content of this bug report
and publishing it to say, OSNews, or perhaps even Linux Gazette would have the
whole open source community behind me.  The entire Microsoft development
community clearly already do agree with me.  I do not stand alone.

Please note:  I am not suggesting that you change the IEE-754 specification, or
even the default IEEE rounding mode. I AM suggesting that when I output an 8
byte floating point number using printf(), one would expect output as per the
Microsoft library.

This has got nothing at all to do with IEEE arithmetic specifications, internal
binary storage or the chosen default IEEE mode for rounding the results of
calculations.  It has everything to do with the implementation of the C99
function printf() and the conversion of an IEEE number verbatim to a character
array representation.

To get a bit more detailed, the IEEE-754 specification for an 8 byte floating
point stores numbers as a sign bit, 10 bits for the exponent and 53 bits for a
mantissa.  It goes ahead and specifies a choice of four rounding modes to
determine the result of mathematical calculations when precision is lost.  It is
clearly more accurate in a accountancy or banking systems to round towards an
even mantissa (not an even integer- an even mantissa) as the error averages out.

Conversely, and most notably, IEEE-754 does not specify what the expected output
should be for the C functions sprintf(), fprintf() and printf().


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4943

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.