Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 801 - *printf with precision >= 16 gives bogus additional digits
Summary: *printf with precision >= 16 gives bogus additional digits
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-01-12 18:21 UTC by Christoph Rohland
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-01-18 22:04:34 UTC


Attachments (Terms of Use)

Description Christoph Rohland 1999-01-12 18:21:26 UTC
#include <stdio.h>

main()
{
    int i;
    for (i=10; i< 20 ;i++)
        printf ("%d: %.*e\n",i,i,12.3456789);
}

gives:

10: 1.2345678900e+01
11: 1.23456789000e+01
12: 1.234567890000e+01
13: 1.2345678900000e+01
14: 1.23456789000000e+01
15: 1.234567890000000e+01
16: 1.2345678899999999e+01
17: 1.23456788999999993e+01
18: 1.234567889999999935e+01
19: 1.2345678899999999345e+01

Comment 1 David Lawrence 1999-01-12 19:27:59 UTC
I have verified this to be true. I compiled and ran the sample of code
on a test lab machine and got the same results. It will be assigned to
a developer.

Comment 2 Cristian Gafton 1999-01-14 07:00:59 UTC
The double number are guaranteed up to 15 precission digits. After
that pretty much nothing is guaranteed or specialized math libs have
to be used.

This is what pretty much standards require off the double precission
implementation.

Comment 3 Anonymous 1999-01-14 07:57:59 UTC
That's only have of the truth...
I do not want to have more digits, but if I give a precision > 16 it
should fill up with zeros and not print some other bogus numbers.

Comment 4 Cristian Gafton 1999-01-18 22:04:59 UTC
One can not blame libm for trying to approximate to its best a double
number out of range. The standards define the behavior as
"unspecified" in this case, so what it happens is perfectly within the
limits of the standards.

Comment 5 Anonymous 1999-01-19 09:32:59 UTC
O.K. I will state at last, that I am not confident with the answer but
do not want to hassle any more.
Porting to RedHat Linux makes this more difficult. Also I could not
find the stated standards restriction in 'ISO/IEC 9899 : 1990
Programming Languages - C'


Note You need to log in before you can comment on or make changes to this bug.