Messages in this thread | | | Date | Sun, 6 Jan 2002 17:09:54 -0700 | From | Tom Rini <> | Subject | Re: [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) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |