noalias macro bug [was: Linux and aliasing?]

[mark@codesourcery.com]

>>>>> "Jamie" == Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

    Jamie> These statements:

    Jamie>   int a = 1; *noalias (short, &a) = 2;

    Jamie> I see how the second reference involves a type-pun to the
    Jamie> memory at the address of `a'.  That means fields `__x__'
    Jamie> and `__y__' of the union are considered to alias: storage
    Jamie> in one clobbers the other.

    Jamie> But how does this alias to `a'?  As far as I can see: it
    Jamie> doesn't.  Prove me wrong.

    Jamie> Basically the fault is in the cast from `int *' to `union
    Jamie> {...} *'.  I think that's of those classic non-conforming
    Jamie> dodgy casts we've been talking about.

The address of `a' is cast to a pointer to a union.  Casting pointers
around is explicitly permitted by ANSI C.  It's *dereferencing* them
that's "dodgy".  (Perhaps Linus' proposal, which focused on the casts,
confused you.)

Then, the pointer to a union, is derefenced.  The compiler treats
accesses through a union as able to alias memory of arbitrary types.
So, the access through the union may alias `a'.  Just like the manual
says.

    Jamie> There has been so much talk of using a union that I thought
    Jamie> it did some magic.  But if the text is definitive, it doesn't.

I have no idea what "magic" you're talking about.  I think you're
confusing (perhaps due to inaccuracies in the manual text) the concept
of a union *variable* and a union *type*.  We're talking type-based
aliasing, so we're talking about types.  You seem to be thinking in
terms of union *variables*, which are variables that have union type.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com