Linux and aliasing?

[mark@codesourcery.com]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

    Linus> On Sun, 6 Jun 1999 mark@codesourcery.com wrote:
    >>  Right.  But the part that's causing aliasing issues is just a
    >> memcpy; that's the `*(u32 *) p' bit.  You could write:
    >> 
    >> memcpy (&a, p, sizeof (a)); a = ntohl (a);

    Linus> Which is crap.

I think that I freely admitted in the posting that this approach is
not as convenient as what you had.  I think you can also see how to
wrap this up in a macro (probably using the already documented, and
hence guaranteed, statement-expression extension).

    Linus> And a compiler that requires you to write code like that
    Linus> is, by implication..

Was that really necessary? :-)

    Linus> If you can't see why

    Linus> 	a = ntohl((u32 *) p);

    Linus> is better than the horrible thing you're suggesting
    Linus> (regardless of whether the code generated is the same or
    Linus> not), then I might as well throw in the towel
    Linus> immediately.

I can see what the "horrible" thing is less convenient for you.  I've
also made sound (in my opinion, naturally) technical arguments against
your proposal, on grounds having not only to do with maintenance of
GCC, but also to do with the impact on code-generation for conforming
programs.  (For example, your proposal, as written, pessimizes:

  int i;	   
  int *ip = &i;
  void *vp = ip;
  *((int*) vp) = 3;

You can amend your proposal to handle the void (and perhaps char?)
case specially, but what about structures with common initial
segments, as used in object-oriented C?  TCL, for example, is one
program that uses this kind of thing heavily.  The Xt toolkit is
another, and there's something that is often performance-critical on a
Linux system.)

So, unless I'm overruled, *something* is going to have to change in

  a =ntohl((u32*) p);

if you're going to enable type-based alias analysis.

BTW, I've been notified in private mail that you pointed out a bug in
GCC's real.c, involving exactly the kinds of casts were arguing about.
(I somehow missed that message from you.)   Thanks for pointing that
out!  I'll fix it soon.

I gather that you suggested your proposal would avoid changing GCC.
But, it wouldn't, since GCC's first stage is compiled with a (possibly
non-GCC) host compiler.  Thus, GCC *must* be written in legal ANSI/ISO
C. 

Even in the kernel, your proposal will lead to a confusing situation.
You claim it's DWIM, but there the "I" really is "Linus Torvalds", and
not necessarily the rest of us.  People used to the ANSI/ISO C
aliasing rules will have to read the GCC manual very carefully to
figure out the meaning of your code.

I think by now you've been presented with a variety of strategies for
solving the problem in the kernel, including more than one idea for
macros that you could use like:

  ALIASING_CAST (type, x)

that would do what you want.  I believe Richard Henderson suggested
one involving local unions; you could also use memcpy as I suggested.
(There may be alignment issues that make my suggestion better, or
maybe not.  I'm not sure.) Using this approach would make your code
clear and self-documenting.  (It would be DWIS!)  This approach is
better than my earlier suggestion (using unions in header files): it
does not require header-file duplication, and requires only local
changes to the kernel.  (What function really could be improved by
type-based alias analysis?  Put it in a separate file.  Use
ALIASING_CAST in it.  Compile *that file* with -fstrict-aliasing.
Performance win, little additional maintenance cost, no impact on the
rest of the kernel.)

Even if we implemented your proposal you'd have to audit all your code
to make sure that all the technically invalid casts come in
expressions that are immediately derefenced, and not stored in
temporaries.

At this point, I strongly suggest you abandon your proposal.  Nobody
looks likely to implement it (at least on a volunteer basis), and I've
pointed out that it will be hard to do so, even if it was agreed that
it was a good thing to do.  Sorry.

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