C undefined behavior fix
Quoted 4 lines
From: Gabriel Dos Reis <[email protected]>
Date: 06 Jan 2002 14:22:45 +0100Isn't the incriminated construct already outside of C and non-portable?
That has been established and agreed upon. What we are now into is pragmatics. You now have to argue why we should not provide this feature in some form to users that ask for it. Love to hear your ideas.
mike stump <[email protected]> writes:
| > From: Gabriel Dos Reis <[email protected]> | > Date: 06 Jan 2002 14:22:45 +0100 | | > Isn't the incriminated construct already outside of C and non-portable? | | That has been established and agreed upon. What we are now into is | pragmatics. You now have to argue why we should not provide this | feature in some form to users that ask for it.
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.
-- Gaby
Quoted 3 lines · Gabriel Dos Reis
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.
Other objections that I have to this solution are:
- it is hard to read; it wouldn't be obvious to someone who doesn't know the details of gcc asm syntax what it is doing or why
- it is a statement, which makes it less convenient to use than an expression
- it requires an extra dummy variable declaration.
But my main objection is that I don't have any assurance that it actually solves the problem in a lasting way.
Paul.
Quoted 18 lines · Paul Mackerras
Quoted 3 lines · Gabriel Dos Reis
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.
Quoted 5 lines
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).
Jakub
Quoted 25 lines · Jakub Jelinek
Quoted 18 lines · Paul Mackerras
Quoted 3 lines · Gabriel Dos Reis
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 5 lines · Tom Rini
Quoted 3 lines · Jakub Jelinek
Quoted 1 line · Paul Mackerras
asm("" : "=r" (x) : "0" (y));
Quoted 7 lines
Quoted 4 lines
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.
If we documented this side effect of such asm statements, one would have to come up with a very strong case to change it.
Signature · 4 lines
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me