Re: "Variables" tutorial available (Windows, mingw/msvc)

From: Buster (none_at_none.com)
Date: 12/16/04 

Date: Thu, 16 Dec 2004 17:33:28 +0000

Alf P. Steinbach wrote:
> * Buster:
>
>>Alf P. Steinbach wrote:
>>
>>
>>>I hope I haven't committed too many errors of my own ( ;-) ), and look
>>>forward to corrections -- just not "it's too long", every word counts.
>>
>>One big error I noticed:
>>
>>
>>>But consider
>>>
>>>x = 0;
>>>x = (x + 7) + (x = 5);
>>
>>[...]
>>
>>
>>>It’s not as bad as the undefined behavior, UB, we have encountered
>>
>> > twice, where the program in theory could crash or hang or willy-nilly
>> > overwrite files on your harddisk, whatever. This is merely an
>> > unspecified result – the standard doesn’t say which of the two results
>> > – but it’s bad enough.
>>
>>I'm afraid it is undefined behaviour, since x is modified twice without
>>an intervening sequence point. That's quite separate from your point
>>about unspecified order of evaluation.
>
>
> Thanks.
>
> I would like some more comments on this though because I'm not
> sure you're right! ;-) In fact I'm quite sure it's not undefined
> behavior because logic dictates so (no possibly undefined thing
> involved, only ordering of evaluation)

Logic dictates nothing in a vacuum (ex nihilo nihil fit, or something
like that) but we can make logical deductions from the standard. This
case seems clear: 5/4 says " ... otherwise the behaviour is undefined"
- the comments in the code examples say "unspecified", therefore one or
the other is wrong. It's unfortunate, but I'm confident the text is
correct and the comments incorrect.

> and the examples in §5/4 are
> equivalent to mine and are noted as _unspecified_ behavior -- so if
> I'm wrong, so is the non-normative part of the standard. But I can't
> find the relevant support for that in the normative text, except to the
> degree simple common sense logic is involved.

You didn't look very hard! Read the last sentence of 5/4.

>>Here's an example with an unspecified result but no undefined behaviour:
>>
>>int f (int & x)
>>{
>> return x += 7;
>>}
>>
>>int g (int & x)
>>{
>> return x = 5;
>>}
>>
>>int x (0);
>>x = f (x) + g (x); // 12 or 17?
>
>
> As far as I can see those examples invoke the same §5/4 as the original
> example? Note that a function call doesn't introduce an ordering
> constraint (sequence point) for the expression in which it appears.

Huh?

In my example, there is a sequence point just before "x += 7" (the
sequence point after the evaluation of all the arguments to f) and a
sequence point just after "x += 7" (the sequence point after the return
value of f is copied). Similarly there are sequence points before and
after "x = 5" in g. So whatever the order of evaluation turns out to
be, the modifications of x in f and g are 'isolated' from each other and
from the final assignment to x. Therefore my example can _never_ invoke
UB.

In your example "x = (x + 7) + x = 5;" there is exactly one sequence
point, which occurs at the end of the full expression. Therefore there
can never be a sequence point between the two attempts to modify x,
and the behaviour is _always_ undefined.

> There are a few sequence points involved in the call itself, namely
> after the evaluation of arguments and after the copying of the return
> value (defined by §1.9/16), but those don't affect the caller.

"those don't affect the caller" is not a very precise statement. I'm not
sure what you mean. 

--
Regards,
Buster

Relevant Pages

  • Re: Must an expression be evaluated before its value is used?
    ... this is not a sequence point. ... The evaluation dependency has a consequence of ... seperate the assignment of 5 to x from the assignment of 11 to x. ... comma operator without first evaluating it's second operand. ...
    (comp.std.c)
  • Scott & Andrei article on DCLP and threading... Flawed ?
    ... am unable to make a solid case for strict ordering of 1,2 and 3. ... "As we tried to point out in the article, sequence points don't offer ... state of the execution environment. ... There is a sequence point at the completion of evaluation of each ...
    (comp.lang.cpp)
  • Re: Linux X demo
    ... precedence to the order of evaluation. ... evaluation of expressions is undefined. ... THE ORDER OF EVALUATION BETWEEN SEQUENCE POINTS. ...
    (alt.lang.asm)
  • Re: Must an expression be evaluated before its value is used?
    ... properly define the ordering of sequence points. ... The evaluation order is defined by the abstract machine (even if it is ... there is a sequence point after the evaluation of the first operand. ... "2 The left operand of a comma operator is evaluated as a void ...
    (comp.std.c)
  • Re: "Variables" tutorial available (Windows, mingw/msvc)
    ... For the benefit of those on this newsgroup who haven't got the standard ... the order of evaluation of operands of individual ... previous and next sequence point a scalar object shall have its stored ... But the standard says that it _is_ undefined behaviour. ...
    (comp.lang.cpp)