From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard Henderson <rth@cygnus.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Tim Hollebeek <tim@wagner.Princeton.EDU>, craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com
Subject: Re: Linux and aliasing?
Date: Wed, 30 Jun 1999 15:43:00 -0000
Message-ID: <19990604152035.B18469@cygnus.com>
References: <199906041539.LAA27085@wagner.Princeton.EDU> <Pine.LNX.3.95.990604084257.5094B-100000@penguin.transmeta.com>
X-SW-Source: 1999-06n/msg00184.html
Message-ID: <19990630154300.-kAPqmDufLaudimKgUTTZHJaLO5tRttAhRA6BRrF8N8@z>

On Fri, Jun 04, 1999 at 08:53:47AM -0700, Linus Torvalds wrote:
> > 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 did.  I'm wary that anything less wouldn't be good enough.

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

This doesn't handle

	extern inline int foo(short *ptr)
	{
		return *ptr;
	}

	int bar(void)
	{
		int i;
		i = 0;
		return foo((short *)&i);
	}

Which isn't unlike some uses of inlines in the kernel.


r~