This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Assignment to volatile objects


Zoltán Kócsi schrieb:
Paul_Koning@Dell.com> wrote:

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 implementation choice).

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++);
- etc.

against benefit for the user. I don't really see benefit.

There are more important things than this in a compiler, and a warning is fine.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]