Re: printf issues

[Morten Welinder <mwelinder@gmail.com>]

> Were you able to determine what data it clobbers (in practice;
> obviously this is compiler-specific) and whether the clobber
> has any observable effects?

It clobbers uninitialized parts of "big".  If you add

    for (i = 0; i < sizeof(big)/sizeof(big[0]); i++) big[i] = 12345678;

then it will consistently print "1.23E+16" which is a bit off, :-)  If
you instead
initialize like this:

    for (i = 0; i < sizeof(big)/sizeof(big[0]); i++) big[i] = 999999999;

then I get "1E+15939" which is fairly impressive.  Also, in this case it will
clobber whatever happened to come before "big".

Morten



On Fri, Apr 4, 2014 at 5:08 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Fri, Apr 04, 2014 at 04:22:46PM -0400, Morten Welinder wrote:
>> Another printf issue has shown up, this time with memory corruption.
>>
>>     printf ("%.3E\n", 999999999.0);
>>
>> The rounding test correctly decides that it needs to round this value
>> up to 1E+09.  It is, however, utterly unprepared for having nowhere to
>> put the carry.  It happily accesses and changes one or more elements
>> before the one that held 999999999.
>
> I suspect this may be true; if so, it's a very nice catch. Were you
> able to determine what data it clobbers (in practice; obviously this
> is compiler-specific) and whether the clobber has any observable
> effects?
>
> Rich