[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D5B0EE30-B301-4C48-A694-DC7AA4CBC9A3@trust-in-soft.com>
Date: Mon, 10 Apr 2017 09:51:01 +0000
From: Pascal Cuoq <cuoq@...st-in-soft.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: *scanf, wrong types in va_arg, and strict aliasing
> On 10 Apr 2017, at 11:31, Pascal Cuoq <cuoq@...st-in-soft.com> 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:
>
> https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfscanf.c?id=54807d47acecab778498ced88ce8f62bfa16e379#n22
>
> https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfscanf.c?id=54807d47acecab778498ced88ce8f62bfa16e379#n146
>
> 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.
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.
