On Tue, 31 Jan 2012 00:38:15 +0100 Georg-Johann Lay <a...@gjlay.de> wrote:
> 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. The user (me, in this case) does not refuse writing robust code, because he has no other choice, warning or not. The user is kindly asking to accomodate his wish to write concise and more elegant code which is not five times longer just to get around a language ambiguity (i.e. robust). > 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. I think there is a rather important difference between the volatile case and the others. Accessing a volatile is a side effect and so is the postincrementing of the object. In the increment case you do know that the side effects will happen before the next sequence point, you just do not know exactly when within the two enclosing sequence points. With the a=b=0 case the side effect of reading b may or may not happen at all. That, I think, is a major difference. In fact, I think there is an even bigger ambiguity with the volatile. Consider the case of the single statement of a = 0; where a is volatile. a=0; is an expression statement. Such a statement is evaluated as a void expression for its side effects, as per 6.8.3.2. A void expression is an expression of which the value is discarded, as per 6.3.2.2. Thus, the value of a=0 should be calculated and then discarded. Since evaluating the value of that expression when 'a' is volatile may or may not read 'a' back, as per 6.5.16.3, the compiler thus has every right to randomly generate or not a read after writing the 0 to a. That is, a simple assignment has an unpredictable side effect on volatile objects. Nothing in the standard says that you must not actually calculate the value of an expression statement before discarding it, actually it explicitely states in 5.1.2.3.4 that you must not omit parts of an expression evaluation which have side effects even if the expression's value is not used. The read-back of a volatile lhs of an expression is a side effect, which, according to the standard, the compiler can emit or omit at whim. And with that writing 'robust' code becomes impossible, as long as it matters to you whether the a=0; statement will read back the volatile 'a' or not. Zoltan
