Velocity Reviews > Undefined Behavior. ..

# Undefined Behavior. ..

coolguyaroundyou@gmail.com
Guest
Posts: n/a

 11-15-2008
Will the following statement invoke undefined behavior :

a^=b,b^=a,a^=b ;

given that a and b are of int-type ??

Be cautious, I have not written a^=b^=a^=b ; which, of course, is
undefined. I am having some confusion with the former statement!

Also, state the reason for the statement being undefined!

Joachim Schmitz
Guest
Posts: n/a

 11-15-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Will the following statement invoke undefined behavior :
>
> a^=b,b^=a,a^=b ;
>
> given that a and b are of int-type ??

No, because the comma operator constitutes a sequence point

> Be cautious, I have not written a^=b^=a^=b ; which, of course, is
> undefined. I am having some confusion with the former statement!
>
> Also, state the reason for the statement being undefined!

6.5.17.1
The left operand of a comma operator is evaluated as a void expression;
there is a sequence point after its evaluation.

Bye, Jojo

c.lang.myself@gmail.com
Guest
Posts: n/a

 11-15-2008
<<Be cautious, I have not written a^=b^=a^=b ; which, of course, is
undefined. I am having some confusion with the former statement!>>

I think this expression is valid as assignment operator is evaluated
from right to left so it is parsed as
(a^=(b^=(a^=b)))
above expression swaps two numbers
please correct me if i am wrong...

Joachim Schmitz
Guest
Posts: n/a

 11-15-2008
(E-Mail Removed) wrote:
> <<Be cautious, I have not written a^=b^=a^=b ; which, of course, is
> undefined. I am having some confusion with the former statement!>>
>
> I think this expression is valid as assignment operator is evaluated
> from right to left so it is parsed as
> (a^=(b^=(a^=b)))
> above expression swaps two numbers
> please correct me if i am wrong...

This is modifying 'a' twice without an intermediate sequence point ->
undefined behavoir

Bye, Jojo

maverik
Guest
Posts: n/a

 11-15-2008
On Nov 15, 3:18*pm, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> <<Be cautious, I have not written a^=b^=a^=b ; which, of course, is
> undefined. I am having some confusion with the former statement!>>
>
> I think this expression is valid as assignment operator is evaluated
> from right to left so it is parsed as
> (a^=(b^=(a^=b)))

6.5.17

1.
expression:
assignment-expression
expression , assignment-expression

2.
The left operand of a comma operator is evaluated as a void
expression; there is a sequence point after its evaluation. Then the
right operand is evaluated; the result has its type and value.

So, you have:

a^=b, b^=a, a^=b
[expression][assignment-expression]
|
a^=b, b^=a
[expression][assignment-expression]
|
a^=b
[assignment-expression]

OTOH, a^=b, b^=a, a^=b
[left operand] [right operand]

Left operand evaluted as void, and comma epression has a type and
value of right operand: a^=b.
But left operand if: a^=b, b^=a
And again: a^=b, b^=a
[left operand] [right operand]
Left operand evaluted as void, and comma epression has a type and
value of right operand: b^=a.

So, the sequnce should be like:
evalute a^=b, then b^=a, then a^=b.
You should get the same result as in this case:

a^=b;
b^=a;
a^=b;

James Kuyper
Guest
Posts: n/a

 11-15-2008
(E-Mail Removed) wrote:
> Will the following statement invoke undefined behavior :
>
> a^=b,b^=a,a^=b ;
>
> given that a and b are of int-type ??

That's perfectly safe. As a stand-alone statement, it is exactly
equivalent to

a^=b;
b^=a;
a^=b;

The use of the comma operator is only needed in cases like if(A; B; C),
where A, B, and C can only be a single statement. In any other context,
I'd recommend breaking it out into three separate statements, but only
for the sake of clarity - it's perfectly legal as a single statement.

> Be cautious, I have not written a^=b^=a^=b ; which, of course, is
> undefined. I am having some confusion with the former statement!
>
> Also, state the reason for the statement being undefined!

6.5p2: "Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation of an
expression".

Because the second version violates a "shall" occurring outside of a
"Constraints" section, the behavior is undefined.

The key difference between the two statements is the presence of the ','
operators in the first version. The ',' operator inserts a sequence
point separating it's two operands.

c.lang.myself@gmail.com
Guest
Posts: n/a

 11-15-2008
On Nov 15, 5:24*pm, "Joachim Schmitz" <(E-Mail Removed)>
wrote:
> (E-Mail Removed) wrote:
> > <<Be cautious, I have not written a^=b^=a^=b ; which, of course, is
> > undefined. I am having some confusion with the former statement!>>

>
> > I think this expression is valid as assignment operator is evaluated
> > from right to left so it is parsed as
> > (a^=(b^=(a^=b)))
> > above expression swaps two numbers
> > please correct me if i am wrong...

>
> This is modifying 'a' twice without an intermediate sequence point ->
> undefined behavoir
>
> Bye, Jojo

sorry,I am still not able to get it...

now again consider a^=b^=a^=b
when compiler see this expression it starts from RHS as assignment
operator is right associative
so first it has to calculate rightmost a^=b then value of a must have
to change....it porceedes then to calculate b^=a ..then again a^=b....

as we can also use a=b=3;
Do you mean that after right most a^=b,we can not be sure that value
of a is changed till we get sequence point...
but a=b=3 is valid

Please clear my confusion...
thanks,

maverik
Guest
Posts: n/a

 11-15-2008
On Nov 15, 3:34*pm, pete <(E-Mail Removed)> wrote:
> You don't have any comma operators in the code that you quoted.

Ok, I mean this: a^=b,b^=a,a^=b; of course

vippstar@gmail.com
Guest
Posts: n/a

 11-15-2008
On Nov 15, 2:39 pm, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> On Nov 15, 5:24 pm, "Joachim Schmitz" <(E-Mail Removed)>
> wrote:
>
> > (E-Mail Removed) wrote:
> > > <<Be cautious, I have not written a^=b^=a^=b ; which, of course, is
> > > undefined. I am having some confusion with the former statement!>>

>
> > > I think this expression is valid as assignment operator is evaluated
> > > from right to left so it is parsed as
> > > (a^=(b^=(a^=b)))
> > > above expression swaps two numbers
> > > please correct me if i am wrong...

>
> > This is modifying 'a' twice without an intermediate sequence point ->
> > undefined behavoir

>
> > Bye, Jojo

>
> sorry,I am still not able to get it...

What don't you get?

> now again consider a^=b^=a^=b
> when compiler see this expression it starts from RHS as assignment

Wrong, when the compiler sees that expression, he can do whatever he
wants because that expression invokes undefined behavior.

> operator is right associative

Uh, no, it's UB.

> so first it has to calculate rightmost a^=b then value of a must have

Uh, no, it's UB.

> to change....it porceedes then to calculate b^=a ..then again a^=b....

Uh, no, it's UB.

> as we can also use a=b=3;

That's different than the former expression, because in that
expression a and b are modified only once between sequence points.

> Do you mean that after right most a^=b,we can not be sure that value

No, a^=b^=a^=b invokes UB and if you have that in your code, you can't
be sure of anything at all.

> but a=b=3 is valid
> Please clear my confusion...

For the reasons I explained before. Now I have a question: How the
hell do you know that a = b = 3 is valid if you don't understand and
you're confused?

Harald van Dĳk
Guest
Posts: n/a

 11-15-2008
On Sat, 15 Nov 2008 04:56:25 -0800, vippstar wrote:
> On Nov 15, 2:39 pm, "(E-Mail Removed)" <(E-Mail Removed)>
> wrote:
>> now again consider a^=b^=a^=b
>> when compiler see this expression it starts from RHS as assignment

>
> Wrong, when the compiler sees that expression, he can do whatever he
> wants because that expression invokes undefined behavior.

When the compiler sees that expression, it cannot be sure whether it will
be executed. It must compile the code, and if the program reaches the
point where the expression is evaluated, _then_ the behaviour is
undefined. The compiler cannot do whatever it wants. The compiler can make
the resulting code do whatever it wants.

>> operator is right associative

>
> Uh, no, it's UB.

Uh, yes, ^= is right associative. The behaviour is undefined but that does
not affect parsing.