Linux and aliasing?

Linus Torvalds torvalds@transmeta.com
Fri Jun 4 08:55:00 GMT 1999


On Fri, 4 Jun 1999, Tim Hollebeek wrote:
> 
> If you do the same type tricks but use intermediate variables to
> improve readability, you lose.  In fact, simply taking an expression
> and decomposing it into constituent parts can change the behavior of
> code under this rule.  Absolutely horrible.

Uhh. You're right. I considered it, but I didn't find it "absolutely
horrible", I thought it could be considered a feature in that it was only
ever entirely local to =one= memory operation. 

That's not something new per se: the gcc __extension__ thing is kind of
similarly meant to silence things up locally to that expression.

But I can see why you wouldn't like it, and I understand your argument. I
don't how how else you would limit the scope of anything like this, though
(scoping it to something larger than a single dereference sounds like a
horrible rats nest to me, but opnions can certainly differ).

> Unless you're suggesting data flow analysis to figure out which
> pointers values could have been derived from a casted pointer??? ick,
> ick, ick.

Oh, no, no, no. Shudder. I hope nobody took it that way. Barf.

I meant the features as something to expressly allow a local override.
Think of the rule more as an issue of "poisoning" the dereference operator
rather than poisoning the _pointer_. In a kind of silly "precedence rule"
notation, it would be

	*(char *)y

becomes (*(char *)) y where it is the "*(char *)" thing that makes the
alias go away. (Now somebody is going to flame my ass off for mixing C and
a non-C precedence rule). 

And maybe the above is hard to do because by the time you actually would
want to do the above logic the information isn't really there any more. 
That's entirely possible, and if people tell me it's a bad idea for reason
X I'll shut up about it, but I'd try to come up with another one. Deal? 

		Linus



More information about the Gcc mailing list