Bit Pattern Problem

[Christian Bau]

If you had:
if ((c=b)==f(c))
or:
if ((a=c)==f(c))
you would have undefined behaviour.

The second one has no undefined behavior.

 

[Flash Gordon]

In the latter case c is being accessed only to extract its value,
not to alter it. Assuming it is not a volatile value.

Sorry, I flipped languages for a moment to one that allows pass by
reference.

 

[Arthur J. O'Dwyer]

(e-mail address removed) (Mark Piffer) wrote...

Ok, how about the following:
int a,b,c;
int f(int);

if( (a=b) == f(c) ) { // undefined behaviour?
}

As the order of execution is unspecified (is it?), the evaluation
sequence could be:[1] a=b
[2] f(c) // sequence point (according to 6.5.2.2/10)
[3] == // using the result of [1] and [2]

[...]
Can someone enlighten me about this? Either I got ignored or the
posting vanished too soon from the servers, but I think the question
isn't trivial (ok, for regulars here maybe it is) and certainly not
OT.

The order of evaluation of a=b and f(c) does not affect the result in
this case, so why would it be undefined behaviour?

Because the Standard says so. Dan Pop's response is correct, as usual;
and most of the other replies are wrong. If you're having trouble
figuring out why the Standard says it's UB, it might help to consider the
perfectly reasonable function definition

int f(int x) { a = x; }

(Then again, it might not. ;-)

Admittedly the value
of a might not be updated until after the comparison has been done, but
the comparison still has to be done against the correct value.

Not if it's undefined.

If you had:
if ((c=b)==f(c))
or:
if ((a=c)==f(c))
you would have undefined behaviour.

Those examples aren't any different from the original example; in fact,
they're just special cases of the original (the first where a:=:c and the
second where b:=:c).

HTH,
-Arthur

 

[Old Wolf]

(e-mail address removed) (Mark Piffer) wrote...

if( (a=b) == f(c) ) { // undefined behaviour?

As the order of execution is unspecified (is it?), the evaluation
sequence could be:[1] a=b
[2] f(c) // sequence point (according to 6.5.2.2/10)
[3] == // using the result of [1] and [2]

The order of evaluation of a=b and f(c) does not affect the result in
this case, so why would it be undefined behaviour?

Because the Standard says so. Dan Pop's response is correct, as usual;
and most of the other replies are wrong. If you're having trouble
figuring out why the Standard says it's UB, it might help to consider the
perfectly reasonable function definition

int f(int x) { a = x; }

How about this:

int c;
memset(x, c = 0, sizeof x);

 

[Michael Wojcik]

int c;
memset(x, c = 0, sizeof x);

That looks OK to me. N869 6.5.16p4 says that accessing the result of
the assignment operator *after the next sequence point* causes UB;
that's what made

if ((a=b) == f(c))

undefined (because there's a sequence point after the arguments to f
are evaluated). In your example, the result of the assignment
operator (in "c = 0") is accessed before the sequence point that
occurs when all of memset's arguments have been evaluated, because
accessing it is part of evaluating memset's arguments; hence no UB.

So, curiously enough,

if ((a=b) == c)

is legal, but eg

if ((a=b) == (c,d))

is not, because of the sequence point caused by evaluating the first
operand of the comma operator.

OK, now someone should point out where I got it wrong...

(I'm glad Mark re-posted his question. This was a tricky one, and
I certainly hadn't noticed it before.)


--
Michael Wojcik (e-mail address removed)

The lark is exclusively a Soviet bird. The lark does not like the
other countries, and lets its harmonious song be heard only over the
fields made fertile by the collective labor of the citizens of the
happy land of the Soviets. -- D. Bleiman

 

[Christian Bau]

That looks OK to me. N869 6.5.16p4 says that accessing the result of
the assignment operator *after the next sequence point* causes UB;
that's what made

if ((a=b) == f(c))

undefined (because there's a sequence point after the arguments to f
are evaluated). In your example, the result of the assignment
operator (in "c = 0") is accessed before the sequence point that
occurs when all of memset's arguments have been evaluated, because
accessing it is part of evaluating memset's arguments; hence no UB.

So, curiously enough,

if ((a=b) == c)

is legal, but eg

if ((a=b) == (c,d))

is not, because of the sequence point caused by evaluating the first
operand of the comma operator.

OK, now someone should point out where I got it wrong...

That has been discussed to some length in comp.std.c.

You are not "accessing" the value of the assignment operator. You can
only "access" lvalues. The result of (a=b) is not an lvalue. You can use
it without accessing it.

 

[Michael Wojcik]

You are not "accessing" the value of the assignment operator. You can
only "access" lvalues. The result of (a=b) is not an lvalue. You can use
it without accessing it.

Wouldn't that render N869 6.5.16p4 meaningless? It reads:

If an attempt is made to modify the result of an assignment
operator or to access it after the next sequence point, the
behavior is undefined.

If "access" only applies to lvalues, and the result of an assignment
operator is never an lvalue, then this statement describes a case
that can't occur.

Was this corrected in the final version of C99?

--
Michael Wojcik (e-mail address removed)

Thus, the black lie, issuing from his base throat, becomes a boomerang to
his hand, and he is hoist by his own petard, and finds himself a marked man.
-- attributed to a "small-town newspaper editor in Wisconsin"

 

[Christian Bau]

Wouldn't that render N869 6.5.16p4 meaningless? It reads:

If an attempt is made to modify the result of an assignment
operator or to access it after the next sequence point, the
behavior is undefined.

If "access" only applies to lvalues, and the result of an assignment
operator is never an lvalue, then this statement describes a case
that can't occur.

Please read the start of this thread again where I gave an example.