[lkml]   [2002]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] C undefined behavior fix
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)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.079 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site