Re: [lmi] snprintf() QoI issue [Was: passing objects instead of references to value_cast]

[Vadim Zeitlin]

On Tue, 03 Jun 2008 05:46:51 +0000 Greg Chicares <address@hidden> wrote:

GC> The issue is certainly specific to snprintf(). Now I'm wondering
GC> whether it's a frank defect, and not just QoI. Consider:
GC> 
GC> #include <iostream>
GC> #include <ostream>
GC> #include <stdio.h> // snprintf() (C99, not C++98).
GC> 
GC> int main()
GC> {
GC>     char buf[1000];
GC>     snprintf(buf, 180, "%#.*f", 16, 1e+161);
GC>     std::cout << buf << std::endl;
GC> }
GC> 
GC> C99 7.19.6.1/8 says that for 'f', "The value is rounded to
GC> the appropriate number of digits", whatever that means.
GC> 
GC> MinGW gcc with msvcrt's _snprintf() prints no bogus digits.
GC> MinGW gcc with its own snprintf() prints this:
GC> 
GC> 
100000000000000003774589324822814887066163651282028976933086588120176268637538771050475113919654290478469527765363729011764432297892058199009821165792668120252416.0000000000000000
GC> 
GC> Cygwin gcc with newlib's snprintf() prints this:
GC> 
GC> 
100000000000000003774589324822814887066163700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000000000000

 As another data point,

        perl -e 'printf "%f\n", 1e+161'

(I think this uses the libc printf() under Linux) yields

100000000000000041235571928614721663645330408800024645916264300099830078947422286554935979756841731922142764527267382929687605754771532944385529317252091795734528.000000

so there is the same problem there too. In fact you don't need to use 1e161
to see it, 1e23 already doesn't work (it's output as
99999999999999991611392.000000), although 1e22 does.

GC> What do you think?

 I don't think it's a defect as I can't really find anything ensuring that
this doesn't happen in the standard. The phrase in 7.19.6.1/8 doesn't seem
to apply here.

 In any case, it's clear that this behaviour, defect or not, is wide-spread
in practice and so we must live with it. So, while it's not a serious
problem unlike what I initially thought, I suggest changing the test.

 Regards,
VZ