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

[Greg Chicares]

On 2008-06-02 18:51Z, Greg Chicares wrote:
> On 2008-06-02 09:52Z, Vadim Zeitlin wrote:
> [...]
>> **** test failed:
>> '100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
>> ==
>> '100000000000000003774589324822814887066163651282028976933086588120176268637538771050475113919654290478469527765363729011764432297892058199009821165792668120252416'
>> [file value_cast_test.cpp, line 331]
>> 
>> I didn't look at it yet but this doesn't look especially good...
> 
> Relative error on the order of (1+DBL_EPSILON) or so? I suspect
> that the test as written requires more than C99 requires, so that
                        ...expects  more than C99 guarantees...
> this is just a QoI issue for snprintf(). If that guess is correct,
> then the test should be liberalized ever so slightly.

The issue is certainly specific to snprintf(). Now I'm wondering
whether it's a frank defect, and not just QoI. Consider:

#include <iostream>
#include <ostream>
#include <stdio.h> // snprintf() (C99, not C++98).

int main()
{
    char buf[1000];
    snprintf(buf, 180, "%#.*f", 16, 1e+161);
    std::cout << buf << std::endl;
}

C99 7.19.6.1/8 says that for 'f', "The value is rounded to
the appropriate number of digits", whatever that means.

MinGW gcc with msvcrt's _snprintf() prints no bogus digits.
MinGW gcc with its own snprintf() prints this:

100000000000000003774589324822814887066163651282028976933086588120176268637538771050475113919654290478469527765363729011764432297892058199009821165792668120252416.0000000000000000

Cygwin gcc with newlib's snprintf() prints this:

100000000000000003774589324822814887066163700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000000000000

What do you think?