Re: printf issues

[Morten Welinder <mwelinder@gmail.com>]

I *think* the right fix is to add the following "if' statement into
the rounding loop:

                while (*d > 999999999) {
                    *d--=0;
                    if (d < a) *--a = 0;
                    (*d)++;
                }

This also ought to make the d<a test afterwards unnecessary.  But
more tests would be better.

M.




On Fri, Apr 4, 2014 at 6:50 PM, Morten Welinder <mwelinder@gmail.com> wrote:
>> 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