Re: Linux and aliasing?

[Linus Torvalds <torvalds@transmeta.com>]

On Sat, 5 Jun 1999, Jamie Lokier wrote:
> Jamie's suggestion de jour.

I like your suggestion - it dos sound like a lot more work especially for
the compiler than my simplistic one, but the fact that we would at least
get warnings from the compiler about them means that we wouldn't have to
rely on somebody going through 30MB worth of sources by hand..

>   Linus wants non-union (ie. non-ugly) casts to do the sensible thing.
>   What that is isn't quite clear -- after thinking it through.
>   If it's just aesthetics, I don't see why a macro wouldn't do ;-)

A macro can do the same thing (the same way I think the current gcc lvalue
cast could be done with a macro), but my approach has the in my opinion
very useful behaviour that it makes most "normal" type cast problems just
automatically do the right thing. So in many cases it would work as-is
(not just for kernel code), and in cases where it does not (ie the cast is
non-local) my proposal has a way out (add another cast that _is_ local
to the actual de-reference).

I don't really see why people hate the proposal so much, but maybe that's
just my personal coding style. I do not consider pointer casts (or any
other kinds of casts) acceptable programming practice for any normal
cases, so just about =all= the casts I ever see are of the type where
alias information should obviously be disabled. So to me it sounds like a
"natural" way of doing things.

(Just to clarify - it's not as if the linux kernel does a _lot_ of ugly
pointer stuff. It's just that it does happen, and it isn't done in one one
well-defined area or similar.)

It seems that other people use more casts for "normal" things, and are
actually afraid of my proposal for performance reasons. I'm surprised:
people that do things like that are usually not the people who complain
about others coding standards ;)

Anyway, I grepped the kernel for "likely" places where my change would
make a difference by using the following heuristic grep:

	grep '\*(.*\* *)' */*.c

and in basically all cases the compiler would have done the right thing if
it had followed my proposal.

THAT is why I like it. It does the RightThing(tm), with basically zero
complexity for either the user or the compiler. It is a "do what I mean" 
kind of patch. 

"Do what I mean" is a quality of implementation thing. Yes, all of this is
obviously not defined by the standard. But exactly because it is NOT
defined by the standard, it's very good if the behaviour is what you'd
expect.

The people who worry about the thing being a performance problem for them:
try the above grep and see what it shows you. No, the grep doesn't really
catch all the cases that the compiler change would impact, but it should
give you a rough idea.

In particular, if the grep comes up empty (ie "Well written code without
any strange casts"), you probably wouldn't actually be impacted by the
"Linus proposal" at all. 

>   In particlar, a cast may be conforming, in which case the compiler
>   should strive the generate the best allowed code (unless it's
>   pathological).

"may be conforming", yes. Are there any real life cases where it really
matters? The case where my rule kicks in is definitely "suspicious" - I
agree that it _may_ conform, but do people actually ever write code like
that in strictly conforming programs? That's why I'd like to see what the
grep above shows people..

>   Issues raised: 
> 
>   - Lots of legacy code uses casts, assuming nothing weird will happen.
>   - Weird things now happen.

Right. The "Linus proposal" would not make that go away completely, but it
would make a large percentage of the weird cases do what the old code
expected.

>   - "non-conforming cast implies pointer may alias all" + "full flow
>     analysis" got proposed.  No one likes it.  Bin.

Yes.

>   - "non-... all" + "*no* flow analysis" got proposed by Linus.  It's a
>     simple special case, arguably syntactic.  But it has semantic warts:
>        *(foo_t*) &bar = foo; 
>     now means something different than:
>        { foo_t* p = (foo_t*) &bar; *p = foo; }

I understand that people can see this as a wart, but if you consider it
syntactic then you shouldn't even _expect_ the above to be the same thing.

In fact, I'd like to consider it a bonus that you will =not= get the
looser alias semantics for the case where you actually assign the pointer.
So you can use the second version as a way to _avoid_ the "Linus rule" if
you like it in general but in a specific case want to disable it.

I guess I'm not convincing you.

>   - "type attribute" got proposed by Linus too.  This I like.

Well, that one is just the "implementation part" of my basic proposal.

It can be done on its own without the "implied no-alias" of course. But I
_meant_ it to be done in conjunction with my other proposal, just
explaining how it would be implemented.

> Jamie's thought of the day
> --------------------------

[ deleted ]

Hey, works for me. It seems to do the Linus proposal in a "warning sense",
if I understood you correctly, with a way to just force whichever actual
semantics you want. Right?

		Linus