Re: [MinGW-dvlpr] New releases of mingw-runtime and w32api

[Keith M. <kei...@us...>]

On Saturday 28 June 2008 02:02:03 Greg Chicares wrote:
> If you bundle it, I'll test it. Actually, let me give you my
> tests now...

Thanks, Greg.  Your test program, compiled with MinGW g++-3.4.5 on 
Ubuntu Hardy, and run under wine, with my replacement formatting 
engine, yields:--

len is 4 (4 is expected)
len is 2 (2 is expected)
ten is '10' ('10' is expected)
ten is '10' (failure is expected)
signed char: '-3' ('-3' is expected)
%d output: '11' ('11' is expected)
%hhn output: '2' ('2' is expected)
guard 0: '55' ('55' is expected)
guard 2: '77' ('77' is expected)
len is 2 (2 is expected)
len is 14 (14 is expected)
e is '2.718281828459' ('2.718281828459' is expected)
e is '2.718281828459' ('2.718281828459' is expected)
x is '1e+007' ('1e+07' is expected)
len is 11 (11 is expected)
x is '3.141590000' ('3.141590000' is expected)
x is '      inf' ('inf' or 'infinity' is expected)
x is '      nan' ('nan' is expected)
len is 179 (179 is expected)
len is 179 (179 is expected)
d is '0x1.c73892ecbfbf4p+534' (internal representation, '%a' format)
d is
 '100000000000000003774589324822814887066163651282028976933086588120176268637538771050475113919654290478469527765363729011764432297892058199009821165792668120252416.0000000000000000' 
('100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000000000000' 
is expected)

> The issues I've identified with the libmingwex snprintf() are:
>
>  - the "%hhn" issue explained in the message cited above, which
>    seems to stomp on memory it doesn't own...with MinGW gcc
>    version 3.4.4 but not with version 4.3.0

I appear to be getting correct behaviour here, but I'm puzzled why 
there would be a difference between 3.4.5 and 4.3.0.  Are you sure 
the mingw-runtime versions are the same in both cases?  Perhaps this 
had already been addressed; I know Danny did apply some patches for 
various mingw_snprintf issues.

>  - NaN and Infinity: I think C99 requires either all capitals,
>    or all lower case; I'm unsure whether or not it says they're
>    padded with blanks when a width is given

I too think C99 requires either all capitals, (for "%E", "%F" 
and "%G"), or all lower case, (for "%e", "%f" and "%g"); this is 
certainly true of SUSv3/POSIX, and it is one of the issues I have 
taken care to address.

>  - Printing 1e+161 in fixed instead of scientific notation gives
>    10000000000000000377[...], whereas the msvc rtl prints no
>    nonzero digit after the initial '1'. Probably a QoI issue as
>    discussed here:
>    http://lists.nongnu.org/archive/html/lmi/2008-06/msg00017.html

This is a (broken) feature of David Gay's gdtoa formatting algorithm, 
which quite happily generates insignificant digits way beyond the 
available precision of the IEEE floating point representation, (this 
is able to represent *at* *most* 17 decimal digits for an 8-byte 
`double'.  Notice that the displayed result is correct, up to this 
limit of precision, and the `377...' appearing from the 18th digit 
onwards is just random garbage.  I haven't looked into fixing that 
(yet), but interestingly the native printf implementation on Ubuntu 
Hardy prints what appears to be identical garbage for this case, 
which I suppose might be expected, because the two internal 
representations, as shown by the

  printf( "d is '%a' (internal representation, '%%a' format)\n", d );

which I've added, are identical for the two platforms.

> Here's my test program:
> [...some code snipped...]

>     snprintf(buf, 20, "%ld", 10LL);
>     std::cout << "ten is '" << buf << "' (failure is expected)\n";

Why do you expect failure here?  I would expect nothing other than 
the '10', which we actually see, since the formatting engine will 
simply take the least significant 4 bytes of the 8 byte long long, 
(this, given the little-endian byte order, will have a value of 10), 
as the argument, and format it accordingly.  Where I would expect 
failure, is in the formatting of any *subsequent* argument, (but 
there is none in this case), since the extra 4 bytes of the long long 
argument will interfere with the correct retrieval of *all* following 
arguments, (the correct argument values will be offset by 4 bytes 
from where the formatter attempts to read them).

Regards,
Keith.