473,903 Members | 4,060 Online

# x=(x=5,11)

Is this defined or not? Some people in ##c are saying that it has to
result in x being set to 11, i'm saying it's undefined. Who's right?
May 27 '06
111 4952
On 28 May 2006 13:34:28 -0700,
en******@yahoo. com <en******@yahoo .com> wrote:

Jordan Abel wrote:
On 2006-05-27, en******@yahoo. com <en******@yahoo .com> wrote:
>
> Richard Tobin wrote:
>> In article <11************ **********@j33g 2000cwa.googleg roups.com>,
>> Robert Gamble <rg*******@gmai l.com> wrote:
>>
>> >> >> > x=(x=5,11);
>>
>> >"In simple assignment (=), the value of the right operand is
>> >converted to the type of the assignment expression and replaces the
>> >value stored in the object designated by the left operand."
>>
>> >Now how is it possible to obtain the value of the right operand and
>> >convert it to the type of the assignment expression without evaluting
>> >it before you store the result in x?
>>
>> Clearly it's not possible to store the result before evaluating it,
>> but it's possible (indeed, easy!) to determine the value of (x=5,11)
>> before performing the assignment of 5 to x.
>
> No, it isn't, because of the sequence point rule for the comma
> operator.

Repeat after me:

Sequence points define a partial ordering.

You seem to think that sequence points are the only thing
that affect the partial ordering of expression evaluation.
That's false. In the expression a + b - c, the evaluation
of + must precede the evaluation of - in the abstract
machine. And compiled code must behave as if
the abstract machine would behave.

So you think

x ^= y ^= x ^= y;

has defined behaviour? After all, just as +/- associates L to R, ^=
associates R to L.

Tim.

--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/
May 28 '06 #41
en******@yahoo. com said:
In the expression a + b - c, the evaluation of + must precede the
evaluation of - in the abstract machine.

C99, 6.5(3): Except as specified later (for the function-call (), &&, ||,
?:, and comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified.

In the expression a + b - c, the abstract machine is under no obligation to
evaluate + before - or vice versa. Indeed, even a, b, and c themselves
might be evaluated in any order.

To bring this back into the context of the thread topic, it is clear that
the onus is on the programmer to ensure that the result produced is the
result the programmer expected - and the way to do that is to write clear,
simple code that removes the possibility of undefined behaviour, without
being forced to rely on en*****@yahoo.c om's assurance that this possibility
does not exist.

In this case, this translates to replacing:

x=(x=5,11);

with:

x = 11;

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
May 28 '06 #42
2006-05-28 <<11*********** ***********@j55 g2000cwa.google groups.com>>, en******@yahoo. com wrote:

Jordan Abel wrote:
On 2006-05-27, en******@yahoo. com <en******@yahoo .com> wrote:
>
> Jordan Abel wrote:
>> On 2006-05-27, pemo <us***********@ gmail.com> wrote:
>> > Jordan Abel wrote:
>> >> Is this defined or not? Some people in ##c are saying that it has to
>> >> result in x being set to 11, i'm saying it's undefined. Who's right?
>> >
>> > x=(X=5,11)
>> >
>> > My reading [but what do I know!]
>> >
>> > X=paraen'ed-expression
>> >
>> > So, paraen'ed-expression must be evaluated first
>>
>> Why? The compiler doesn't need to emit code to evaluate it to know the value.
>>
>> I think that the statement
>>
>> char foo[9];
>> x=(x=sprintf(fo o,"hello"),spri ntf(foo," world!\n"));
>>
>> could do things in this order:
>>
>> x=8
>> x=5
>> set foo to "hello"
>> set foo to "world!\n"
>
> You're falling into the trap of arguing what a compiler
> might do rather than what a compiler is obliged to do
> by the Standard.

The "as if" rule applies.

Yes, and the code you posted doesn't behave as if
it were executed by the abstract machine.

The behavior of the abstract machine is not defined by the standard in
this case.
May 28 '06 #43

Jordan Abel wrote:
On 2006-05-27, en******@yahoo. com <en******@yahoo .com> wrote:

Jordan Abel wrote:
On 2006-05-27, pemo <us***********@ gmail.com> wrote:
> Jordan Abel wrote:
>> Is this defined or not? Some people in ##c are saying that it has to
>> result in x being set to 11, i'm saying it's undefined. Who's right?
>
> x=(X=5,11)
>
> My reading [but what do I know!]
>
> X=paraen'ed-expression
>
> So, paraen'ed-expression must be evaluated first

Why? The compiler doesn't need to emit code to evaluate it to know the value.

I think that the statement

char foo[9];
x=(x=sprintf(fo o,"hello"),spri ntf(foo," world!\n"));

could do things in this order:

x=8
x=5
set foo to "hello"
set foo to "world!\n"

You're falling into the trap of arguing what a compiler
might do rather than what a compiler is obliged to do
by the Standard.

The "as if" rule applies.

Yes, and the code you posted doesn't behave as if
it were executed by the abstract machine.

May 28 '06 #44
2006-05-28 <<11*********** ***********@i40 g2000cwc.google groups.com>>, Harald van D?k wrote:
Jordan Abel wrote:
[x=(x=5,11)]
Is this defined or not? Some people in ##c are saying that it has to
result in x being set to 11, i'm saying it's undefined. Who's right?

To use another example:

#include <stdlib.h>
int main(void) {
int *p = 0;
exit(0), *p;
}

Is this a valid C program?

I believe there is no significant difference between this, and
x=(x=5,11). In both cases, the behaviour is defined if and only if the
right operand of the , operator is not ever evaluated before the left
operand is, in both cases there are no side effects in the evaluation
of the right operand, and in both cases and the question is whether the
as-if rule can introduce undefined behaviour when there would otherwise
not be any. Do you agree that this example has the same problem? And if
not, why not? (The reason I'm using this example is because disallowing
it is much more surprising to me than disallowing your original code.)

There is no part of the expression x=(x=5,11) that is not reached.

This does seem a lot like the p=p->next=q discussion, which i'd
forgotten until now, and which I don't think we ever came to a consensus
on.
May 28 '06 #45
Richard Heathfield wrote:
en******@yahoo. com said:
In the expression a + b - c, the evaluation of + must precede the
evaluation of - in the abstract machine.

In the expression a + b - c, the abstract machine is under no obligation to
evaluate + before - or vice versa. Indeed, even a, b, and c themselves
might be evaluated in any order.

I disagree. If the expression is 5 + 6 - 3, then the machine must
compute 5 + 6 before it subtracts 3 (notwithstandin g the as-if rule).

I'm not sure what other possibility you are trying to allow for here?

May 28 '06 #46
Old Wolf said:
Richard Heathfield wrote:
en******@yahoo. com said:
> In the expression a + b - c, the evaluation of + must precede the
> evaluation of - in the abstract machine.

In the expression a + b - c, the abstract machine is under no obligation
to evaluate + before - or vice versa. Indeed, even a, b, and c themselves
might be evaluated in any order.

I disagree. If the expression is 5 + 6 - 3, then the machine must
compute 5 + 6 before it subtracts 3 (notwithstandin g the as-if rule).

Please explain your reasoning in the light of 6.5(3), which I cited

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
May 28 '06 #47
Jordan Abel wrote:

There is no part of the expression x=(x=5,11) that is not reached.

Jordan, in all your posts on this thread you seem to ignore
the fact that the comma operator introduces a sequence point.

The rules of C are that nothing after a sequence point can
be evaluated until all side-effects from expressions prior to
the sequence point have been evaluated.

It is not possible to evaluate "11" before the assignment of
5 to x has completed.

It is not possible to assign 11 to x, before 11 has been evaluated.

By the logic that you are using, there might as well be no
sequence points; for example you would have to say that:

x = 1;
x = 2;

causes undefined behaviour because before 1 is assigned
to x, the compiler can "see" that 2 is going to be assigned
to x.

May 28 '06 #48
2006-05-28 <11************ **********@i40g 2000cwc.googleg roups.com>, Old Wolf wrote:
Jordan Abel wrote:

There is no part of the expression x=(x=5,11) that is not reached.

Jordan, in all your posts on this thread you seem to ignore
the fact that the comma operator introduces a sequence point.

Sequence points are fine, as far as they go, but you're forgetting that
they define a partial ordering.
May 28 '06 #49
Richard Heathfield wrote:
en******@yahoo. com said:
In the expression a + b - c, the evaluation of + must precede the
evaluation of - in the abstract machine.
C99, 6.5(3): Except as specified later (for the function-call (), &&, ||,
?:, and comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified.

In the expression a + b - c, the abstract machine is under no obligation to
evaluate + before - or vice versa. Indeed, even a, b, and c themselves
might be evaluated in any order.

a, b, and c may be evaluated in any order, but the code *must* behave
as if the addition is done before the subtraction. The subtraction may
be done before the addition if and only if in every case, the same
result is generated, because otherwise the as-if rule doesn't apply.