#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
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.
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.
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.
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.
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'