undefined behaviour a[i] = ++i;

[subramanian100in]

Consider

a = ++i;

This will invoke undefined behaviour because the order of evaluation
of operands of an operator is not specified. Is the reasoning
correct ?

Thanks

 

[Richard Heathfield]

(e-mail address removed), India said:

Consider

a = ++i;

This will invoke undefined behaviour because the order of evaluation
of operands of an operator is not specified.

I suppose that, if the order of evaluation were *completely* defined,
the code would be okay, and it isn't so it isn't, and therefore, in a
way, you are right. But if you want the Chapter and Verse, it goes like
this:

"Between the previous and next sequence point an object shall have its
stored value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be accessed only to determine the
value to be stored." (That's from 3.3.)

So the code violates a "shall" requirement that, as it happens, is not
part of a constraint. And within the definition of "undefined behavior"
in 1.6, we find:

"If a ``shall'' or ``shall not'' requirement that appears outside of a
constraint is violated, the behavior is undefined."

 

[Kenneth Brody]

(e-mail address removed), India said:

Consider

a = ++i;

This will invoke undefined behaviour because the order of evaluation
of operands of an operator is not specified.

I suppose that, if the order of evaluation were *completely* defined,
the code would be okay, and it isn't so it isn't, and therefore, in a
way, you are right. But if you want the Chapter and Verse, it goes like
this:

[...]

I don't think this is strictly an "order of evaluation" issue.
Consider:

int i = 2;
int j = i++ + i++;

Strictly speaking, "order of evaluation" would be irrelevent, as
2+3 and 3+2 are both 5, so it doesn't matter which i++ is "evaluated"
first. Unless, by "evaluation" you also mean "all side-effects are
completed as well" -- but that's what "sequence points" are for, as
in your C&V quote.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Richard Heathfield]

Kenneth Brody said:

I don't think this is strictly an "order of evaluation" issue.
Consider:

int i = 2;
int j = i++ + i++;

Strictly speaking, "order of evaluation" would be irrelevent, as
2+3 and 3+2 are both 5, so it doesn't matter which i++ is "evaluated"
first. Unless, by "evaluation" you also mean "all side-effects are
completed as well" --

Well, it would be more accurate simply to admit that I didn't choose my
words, or indeed my thoughts, quite as thoroughly as I should have
done. Thanks for your clarification, which is of course perfectly
correct.

 

[christian.bau]

Consider

a = ++i;

This will invoke undefined behaviour because the order of evaluation
of operands of an operator is not specified. Is the reasoning
correct ?

It is undefined behavior in the C language because the C Standard has
a rule that makes it explicitely undefined.

If you didn't know that rule, but knew that order of evaluation of
operands is not specified in C, then common sense would tell you that
the expression is at least suspicious; if you started with i = 2 then
a [2] = 3 and a [3] = 3 would be two obvious possibilities. In a
language like Java, the behavior is actually defined; in such a
language the expression is just plain horrible.

But something like

a = (i += 0);

also has undefined behavior. And here the only reason is: It is
undefined behavior because the C Standard says so.