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

[Greg C. <gch...@sb...>]

On 2008-06-28 09:21Z, Keith Marshall wrote:
> On Saturday 28 June 2008 02:02:03 Greg Chicares wrote:
[...]
>> 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

3.4.4, actually: a bit out of date, I know.

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

With gcc-3.4.4, I'm using a 2005-08-13 libmingwex that wouldn't
have patches for the "%hhn" issue reported two years later.

That's just the toolchain I use in my job; I never had a strong
enough reason to update to gcc-3.4.5, but maybe I'll update that
libmingwex ere long.

>>  - 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, 

Indeed. Zeros would be less astonishing than random digits, but
I believe C99 permits either.

>> 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).

I agree with your analysis. I think my test was mistaken.