Re: [PATCH] C undefined behavior fix

[Tom Rini <trini at kernel dot crashing dot org>]

On Sun, Jan 06, 2002 at 11:19:40PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 07, 2002 at 08:59:47AM +1100, Paul Mackerras wrote:
> > Gabriel Dos Reis writes:
> > 
> > > Personnally, I don't have any sentiment against the assembler
> > > solution.  Dewar said it was unnecessarily un-portable, but that the
> > > construct by itself *is* already unportable. 
> > 
> > I assume that what we're talking about is using an asm statement like:
> > 
> > 	asm("" : "=r" (x) : "0" (y));
> > 
> > to make the compiler treat x as a pointer that it knows nothing about,
> > given a pointer y that the compiler does know something about.  For
> > example, y might be (char *)((unsigned long)"foo" + offset).
> > 
> > My main problem with this is that it doesn't actually solve the
> > problem AFAICS.  Dereferencing x is still undefined according to the
> > rules in the gcc manual.
> > 
> > Thus, although this would make the problems go away at the moment,
> > they will come back at some time in the future, e.g. when gcc learns
> > to analyse asm statements and realises that the asm is just doing
> > x = y.  I would prefer a solution that will last, rather than one
> > which relies on details of the current gcc implementation.
> 
> Even if gcc learned to analyze asm statements (and use it in something other
> than scheduling), I'm sure this wouldn't be optimized away exactly because
> this construct is used by various projects exactly for this purpose (make
> gcc think it can have any value allowed for the type in question).

Yes, but there's no gaurentee of that.  It'd probably break a few things
if they did, but there's nothing stopping them from doing it.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/