Thread: i=i++

I came across the code i=i++ today. It does increment i, but it surprised me. If post-increment is supposed to return the old value, why is the old value not assigned back to i ? I expected the line to have no effect on i.

If I recall correctly, this is undefined behaviour. It will do different things on different machines, and might do different things if you run your program while eating cheese on a wednesday as opposed to a thursday.

You go to the doughnut shop. The clerk tells you "We have a special today - if you can ID yourself correctly, we'll give you a free donut." You show your ID.

Then the clerk gives you a free donut.

I believe that i would always be incremented. Any day of the week, regardless of the food you eat. The i=i bit is logical nonsense, since obviously i is equal to itself.

It is indeed undefined. You're not allowed to modify an object multiple times without what's called a “sequence point” in between. See Annex C in C99 for a (hopefully complete) list of sequence points in C.

Technically anything can happen, but in reality, a value (maybe not the one you expect) will likely get assigned to “i”. What value depends on how your compiler handles this line. For example, it's perfectly legal for a compiler to do the following:

• Load the value of i somewhere
• Execute the increment
• Store the (previously-loaded) value of i into i

Equivalent code:

Code:

int tmp = i++;
i = tmp;

Voilà: i’s value does not change. Of course, the compiler could also:

• Load the value of i somewhere
• Store the (previously-loaded) value of i into i
• Execute the increment

Equivalent code:

Code:

i = i;
i++;

Now you do get an increment. The moral of the story: don't do that!

For the record, on my system, i is incremented on the following compilers:

• gcc 4.5.1
• Intel
• Solaris Studio (previously Sun Studio)

It is not incremented with:

• gcc 3.4.6
• TinyCC
• pcc
• clang
• Open64
• cparser

Since i = i can't BE a modification, you aren't modifying i more than once, between sequence points.

Turbo C gets this right. The post increment should happen AFTER any other processing before the sequence point is reached.

So how could a standard compliant compiler NOT increment i ?

Compilers that fail this, are brain dead.

Since i = i can't BE a modification, you aren't modifying i more than once, between sequence points.

You misunderstood. The "equivalent code" sections are not supposed to be undefined. They explain, in (defined) C terms, how a compiler might implement i = i++.

Turbo C gets this right. The post increment should happen AFTER any other processing before the sequence point is reached.

So how could a standard compliant compiler NOT increment i ?

If you're talking about "i = i; i++" then yes, as I mentioned, that's where the increment happens. If you're talking about "i = i++", then compilers can do what they want because the standard says that's undefined. You can argue that the standard is brain dead, if you'd like, but not compilers: they're following the spec.

Originally Posted by cas

You can argue that the standard is brain dead, if you'd like, but not compilers: they're following the spec.

Seconded, though I expect there is a very good reason for this in the standard: optimization. Disallowing such a thing, I think, makes optimization easier, better and safer for compilers.

K&R page 105 has a pointer version of strcpy() as this little beauty:

Code:

void strcpy(char *s, char *t) {
   while((*s++ = *t++) != '\0')
   ;
}

Which seems VERY similar to our topical bit of code:

Code:

i=i++;

Despite all other logical machinations, it has an increment to i in it.

If I couldn't trust a compiler to do the latter code correctly, I wouldn't trust it to do the former.

Originally Posted by Adak

K&R page 105 has a pointer version of strcpy() as this little beauty:

Code:

void strcpy(char *s, char *t) {
   while((*s++ = *t++) != '\0')
   ;
}

Which seems VERY similar to our topical bit of code:

Code:

i=i++;

The former does not modify an object twice in between sequence points. The latter does. It's just that simple.

Despite all other logical machinations, it has an increment to i in it.

If I couldn't trust a compiler to do the latter code correctly, I wouldn't trust it to do the former.

Anything a compiler does for i=i++ is correct. It sounds like you're interested in a language that might be called "Adak C"; and indeed, compilers seem to get i=i++ wrong in that language, but they don't get it wrong in C.

@Salem: No such image of how a compiler works. Just an opinion of it's performance.

@cas: Absolutely right! I would make some changes in C, if able.