Linux and aliasing?

[Linus Torvalds]

On 4 Jun 1999 craig@jcb-sc.com wrote:
> 
> Maybe it is -- I haven't looked into the issues in detail -- but,
> generally, it is very hard to implement common sense *in the compiler
> itself*.

Oh, agreed.

But it should be reasonably easy to implement very straightforward rules,
and have the rules themselves make common sense ;)

The extremely straightforward rule that at least I would advocate is _so_
straightforward as to be almost scary:
 - if there is a pointer cast, that pointer cast invalidates all
   type-based alias information.

It wouldn't matter if you cast the pointer to the type it had originally
anyway: a cast is a cast is a cast. If somebody dereferences a casted
value, the type information shouldn't be trusted.

It is a common sense rule at least to me, and it should be very simple for
the compiler too. And it has another advantage: it does not expand the
language in any way, and is obviously entirely ANSI compliant (it's
obviously not a _requirement_ of ANSI, but it is certainly allowed by it). 

_And_ any well-written software that isn't trying to be clever with
pointers would never ever notice anything, because the only reasonable
reason why you would ever use a pointer cast is because you're playing
games with the pointers in question, no?

Having a simple cast rule would make most of the alias issues go away
completely right off the bat, and the ones it wouldn't make go away you
can patch up by hand in the sources by just adding a dummy cast if
somebody is doing something _really_ ugly. 

> For all I know, this problem is the result of C, or gcc, being
> too permissive about allowing casts across pointers to different
> types...in the sense that, if that sort of thing was simply
> disallowed, then programmers wouldn't even *think* they "knew what
> they were doing", because they'd be getting compile-time diagnostics,
> which, as you point out, is what they *should* be getting if the
> compiler isn't basically successfully reading the programmer's mind
> and implementing his desires.

Well, the other way of thinking about this is to just say "oh, the
programmer is casting stuff, let's not trust the type system any more". 

Craig, don't always try to make the programmer look bad. Occasionally you
could just admit to the possibility that the programmer _really_ knows
what he is doing, and the compiler does not. Ok? Instead of blaming the
programmer, please just _allow_ him to say "you're just a stupid compiler,
and you shouldn't be getting too much in my way". Is that so hard to do?

> In particular, while it might make sense for *your* application
> to have the compiler "automatically" disable (even localized)
> aliasing when it sees certain "suspicious" constructs, how do we
> know there won't be people who say "hey, *we* use those constructs,
> but we use them *correctly*, and we don't want to lose the
> performance those alias assumptions give us", either now or in
> the future?  Why should *they* have to pay for their more-
> conforming (to the compiler's growing expectations, anyway) usage
> by modifying their code, or even their shell scripts?

They shouldn't. You should have an option that says

 -fno-strict-alias

(you have it already) and you should have an option that says

 -freally-strict-alias

but you should probably default to something that makes sense (and the
ANSI C rules certainly do _not_ qualify - I see how they were created, but
they do not "make sense" in any sense of that expression). Something that
notices that "oh, they're playing with the type system, I probably
shouldn't do aliases here". Ok?

In fact, the only _really_ sensible type-based alias system is probably
one where the _only_ thing that overrides a type-based alias is a pointer
cast. ANSI C has all the "funny" rules about "char *" being special etc,
and that means that you lose a lot of potentially very useful information. 
So you might consider having a mode that is _stricter_ than ANSI C in that
regard (not making "char *" anything special as far as the type alias
logic is concerned, but instead implementing _just_ the cast rule). 

So you can think of it as a sum of two independent yes/no rules: "do we
consider 'char *' to be a global alias killer" and "does a pointer cast
invalidate the type-based alias for the casted access?". So give the user
_two_ options:

	-fcast-invalidates-type-alias
	-fansi-alias-rule-invalidation

where the compiler would default to having both rules enabled (for the
"safest" kind of type-based alias), while people who really feel confident
that their program is entirely ANSI-alias safe would say that he does not
want the "cast-invalidates-type-alias" logic enabled. 

And in contrast, people like me who think the ANSI C rules are completely
arbitrary and much harder to understand than the cast alias rule, would at
least have the _option_ to use the simpler and more straightforward setup. 
No? 

Again, instead of thinking that the compiler always knows best, give the
user a choice. We're not in Windows any more, Tonto. Give the programmer
the gun, and allow him to shoot himself in the head. But give him a
laser-guided nightsight too, in case he wants it.

Don't get caught up in the MS way of doing things, where you not only give
a programmer a gun, you aim it at (roughtly) the wrong target, and you
pull the trigger for him too. 

Face it, there are clever programmers out there. You shouldn't make it
illegal to be clever. A standard is not a law of nature, and it's not a
universal excuse to be unfriendly to people who want to go outside the
standard.

		Linus