Re: [PATCH] C undefined behavior fix

Tom Rini
2002-01-07T00:11:00Z

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)