2

I have this code:

#include<stdio.h>
main()
{
    static int a[10];
    int  i=5;
    a[i]=i++;// **statement 1**

    printf("%d %d",a[6],a[5]);
}

I get the following output:
0 5
Since the assignment operator is RTL, shouldn't i++;in statement 1 get incremented and then a[i] actually becomes a[6] before assignment?
Doesn't statement 1 evaluate to a[6]=5;?
Why is a[5] becoming 5?

Shivaji_Vidhale
  • 393
  • 1
  • 5
  • 14
  • 1
    http://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points – Binayaka Chakraborty Jul 10 '13 at 19:34
  • It is best to avoid this code. – ondrejdee Jul 10 '13 at 19:35
  • 1
    God I love this site. It's been less than 5 minutes and the response is amazing. As far as the question is concerned, I had no clue about "Undefined behavior" Will do the research now. Thanks a ton :) – Shivaji_Vidhale Jul 10 '13 at 19:43
  • @Shivaji_Vidhale; Better to read [this](http://stackoverflow.com/questions/17574025/undefined-behavior-and-sequence-point) and [this](http://stackoverflow.com/a/9056443/2455888) and also [this one](http://stackoverflow.com/questions/17473706/understanding-sequence-point-in-c?lq=1) – haccks Jul 10 '13 at 19:45
  • @DanielFischer this case not UB. – BLUEPIXY Jul 10 '13 at 22:10
  • @BLUEPIXY It is. "The evaluations of the operands are unsequenced." says the standard about the assignment operator. And "If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object **or a value computation using the value of the same scalar object, the behavior is undefined.**" about expressions in general. – Daniel Fischer Jul 10 '13 at 22:14
  • @DanielFischer this case evaluation sequence. `j = i++;` is 'j = i;' and after `i = i + 1;` – BLUEPIXY Jul 10 '13 at 22:24
  • @DanielFischer A similar example is also used in the sample code of "C : A Reference Manual, Fifth Edition". – BLUEPIXY Jul 10 '13 at 22:28
  • @BLUEPIXY Not necessarily. The storing of the value in `j` is sequenced after the value computation of `i++`. But the storing of the incremented value in `i` can take place before even evaluating `j` to find out where to store the old value of `i`. Now, in `j = i++;` there's no undefined behaviour, but in `a[i] = i++;` there is. `temp = i++; a[i] = temp;` would be a perfectly valid evaluation sequence (well, it's UB, so everything is valid, as far as the standard is concerned, but let's for the sake of argument pretend it's merely unspecified). Now, what if `i` was the last valid index? – Daniel Fischer Jul 10 '13 at 22:32
  • @DanielFischer `temp = i++; a[i] = temp; ` This is certainly UB. But is executed `++` in the middle of the expression evaluation is funny(it's different). – BLUEPIXY Jul 10 '13 at 22:39
  • @BLUEPIXY The point is that the standard gives the implementations great freedom in how they execute programmes. A consequence of that is that many syntactically valid constructs invoke undefined behaviour. The standard even goes out of its way to stress that the evaluations of the operands of an assignment expression are unsequenced. In `a[i] = i++;`, the value of `i` on the left hand side would depend on whether it's evaluated before or after the right hand side, and if after, also on when the incremented value is stored in `i`. The standard takes the easy route and says it's undefined. – Daniel Fischer Jul 10 '13 at 22:49
  • @DanielFischer Hard to believe for me, but I was sure that the behavior is different in the clang and gcc. I thank very much I get to talk with me. thanks!. Can I be left these comments? – BLUEPIXY Jul 10 '13 at 22:53

3 Answers3

1

This is becuase = is not a sequence point for C language. As such, a[i] = i++ invokes undefined behaviour.

This is better explained here, and here (Thanks to Daniel Fischer)

Community
  • 1
  • 1
0

This is an undefined behavior according to language spec ;)

dotixx
  • 1,490
  • 12
  • 23
0

You are trying to access and modify the same variable in the same sequence point (i.e. at the same time). It is an undefined behaviour.

Checkout this question for more information.

Community
  • 1
  • 1
Manu343726
  • 13,969
  • 4
  • 40
  • 75