[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Apr 2014 18:50:18 -0400
From: Morten Welinder <mwelinder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: printf issues
> 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@...ifal.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
