[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

[Sam McCall via llvm-dev]

json::Value in JSON.h is a discriminated union.
The storage is a char array of appropriate type and alignment. The storage
holds one object at a time, it's initialized (and for nontrivial types,
destroyed) at the right times to ensure this. The cast is only to the type
of object that's already there, there's no magic here.


On Fri, Aug 10, 2018, 17:52 Andrew Haley <aph at redhat.com> wrote:

> On 08/10/2018 05:30 AM, Liu Hao wrote:
> > Only an lvalue of a pointer to (possibly CV-qualified) `void` or a
> > pointer to a character type (in C) / any of `char`, `unsigned char` or
> > `std::byte` (in C++) can alias objects.
>
> Yes.
>
> > That is to say, in order to eliminate the aliasing problem an
> > intermediate lvalue pointer is required.
>
> Not exactly.  You can cast a pointer to a pointer to some character
> type or the type of the object stored in memory.  It does not matter
> whether you use an intermediate type or not.  Having not seen the test
> case, I can't tell whether this rule is followed.
>
> What you can't do is store as a double, cast the double pointer to a
> character pointer, cast that pointer to some other pointer type, and
> read from memory.  GCC won't give you a warning for that, but it's
> still undefined.
>
> JSON.h seems to hope that if you cast a pointer to T to a pointer to
> some union type, magic will happen.  It won't work, unless the object
> stored in the memory at that address was stored as the union type.
>
> Do not lie to the compiler or it will get its revenge.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/ba826ae9/attachment.html>