Assignment to volatile objects

[Georg-Johann Lay]

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.