This is the mail archive of the
mailing list for the GCC project.
Re: Assignment to volatile objects
Zoltán Kócsi schrieb:
I would prefer this to generate a warning. The C language standard change
you refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work
one way or the other.
Sure. However, a compiler is a tool and the best thing it can do is to serve
its user's needs. Generate a warning, because there's an ambiguous construct
(actually, it has always been a bit iffy, but now it is officially an
From what you quotet is's "maybe or maybe not", not "implementation
defined". I.e. the behavior may be different for a=b=0 or a=a=a.
When there is a possibility of helping the user, what's wrong with offering it?
A warning would be much of a help to write unambiguous, robust code.
So the question is rather why user refuses to write robust code in the
first place once there is a warning.
If there's a switch and it is being used, then the user explicitely tells
you how (s)he wants the ambiguity to be resolved. The user, by specifying his
or her preference clearly indicates that (s)he is aware of the ambiguity,
i.e. knows what (s)he is doing and asked you kindly to resolve it this way or
the other. You can answer with a "piss off, idiot" or just do what the user
asked you to do. So why not help the user?
IMHO it's about weigh cluttering up compiler souces with zillions of
command line options like
- how to resolve a = b = c; if b is volatile.
- how to resolve i = i++;
- how to resolve f(i++, i++);
against benefit for the user. I don't really see benefit.
There are more important things than this in a compiler, and a warning