Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 10 Apr 2017 09:43:48 -0400
From: Rich Felker <>
Subject: Re: *scanf, wrong types in va_arg, and strict aliasing

On Mon, Apr 10, 2017 at 09:51:01AM +0000, Pascal Cuoq wrote:
> > On 10 Apr 2017, at 11:31, Pascal Cuoq <> wrote:
> > 
> > Besides, since I am reviewing this file, and since I was originally interested in analyzing it for strict aliasing violations (although the analyzer is not ready to handle this file), I should point out the function store_int at line 22 and the way it is used at line 146:
> > 
> >
> > 
> >
> > 
> > This will not go down well with the strict aliasing analyzer, when it is finally ready for this sort of code. And indeed, compiling the previous scanf snippet together with musl's source code while enabling link-time optimization could plausibly produce non-working binary code because of the type-based alias analysis.
> Well I just got the analyzer to accept the file, and while emitting
> tons of false positives that it shouldn't, by not warning for
> store_int it reminded me that writing a signed or unsigned version
> of the intended integer type does not break “strict aliasing” as
> described in 6.5:7. The code assumes that size_t is typedef'd to
> long at line 139, but I no longer think there is has to be any
> strict aliasing problem here.
> Please disregard the second half of my previous message.

The assumption about size_t (and also ptrdiff_t and intmax_t, I think)
is an issue, though. I think I should just add extra size classes for
those rather than trying to make assumptions or deductions about which
underlying types they're defined as, much like the proposed printf fix.


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.