Re: Linux and aliasing?

[Linus Torvalds <torvalds@transmeta.com>]

On Sun, 6 Jun 1999 mark@codesourcery.com wrote:
> 
> 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.

Note that I didn't point it out as a kind of "nyaah, nyaah!" kind of
thing: it just happens that I had the gcc sources on-line and thought I'd
idly check whether it looked like it could have problems just to make
people realize how PERMEATING this is.

> 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. 

My proposal is not just about "avoiding changing X", whether X be gcc, the
kernel, or anything else.

What I _really_ wanted to point out that even among the people who (a)
should know and (b) now quote the standard as a legal reason to do
anything, these kinds of things happen. 

My proposal is really a way of saying "ok, there is old code out there,
and we want to try to be as graceful about it as we can".

In the case of the Linux kernel, that "gracefulness" would be something I
would be really happy to take advantage of, as I don't expect to compile
the kernel with much else.

> 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.

No. People used to the ANSI/ISO C aliasing rules (all five of them) will
just point to the code and say it is not strictly conforming, and then
they will go back to building their ivory towers. 

It's not just the kernel. It's not just gcc. I bet there are things like
this in just about all major projects - some of which we'll never see
source code for. 

My proposal might mean that fewer people will use the "-fno-strict-alias"
switch, because they won't have to. I don't think you realize how most
professional software projects work. The "professional" part means that
people are under a deadline and don't really care about your standards
conformance, they want things to WORK. 

That may not be your definition of professional, but it's a fact of life. 

That means that I suspect that if there isn't some simple workaround (like
mine), then it's not just the kernel project that uses the disable switch.
Is that what you want?

Flexibility is a GOOD thing. Even if that flexibility means "Oh, you don't
_have_ to program to the standard, and I'll still try to do the best I
can". 

Think of it this way: you still support "-traditional -O2" - you try to
generate good code even when presented with C that isn't even called C any
more.

Why? Because the code is out there, and it's not worth changing thousands
of software packages when you can instead change one: the compiler.

> 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)

I've been told in private email, that the proposed macro wasn't even
standards conforming in the sense that it doesn't guarantee that the
compiler couldn't decide it aliases (because in order to guarantee that
the union should contain all possible types). It happens to work for gcc. 

I don't know whether that is true - I don't have the official standard
around. But you might want to check that out.

> that would do what you want.  I believe Richard Henderson suggested
> one involving local unions; you could also use memcpy as I suggested.

Or I could use "-fno-strict-alias" which is actually preferable to
starting to introduce ugly code.

I think it was Craig who complained about maintenance. "Ugly code" is a
big maintenance issue, and it's always much much better if the "obvious"
code works even if it is not "strictly conforming". The kernel doesn't try
to be strictly conforming anyway, we use tons of other things.

> 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.

Sure. But it wouldn't result in horribly ugly code.

I'm not using egcs at the moment. As such, I'm just seeing reports saying
that it's broken wrt the kernel. My reaction is still that people should
just use gcc-2.7.2, because it's just too _painful_ to upgrade to egcs.
Oh, well..

> At this point, I strongly suggest you abandon your proposal.  Nobody
> looks likely to implement it (at least on a volunteer basis),

Andy Kleen already said he was playing with patches that implemented it,
but just ignore that, like you ignore all the other arguments I've
presented. Sorry,

		Linus