multiple pre increment/post increment in expression of C language

The version of the C standard you quote, page 76:

84) This paragraph renders undefined statement expressions such as

i = ++i + 1;

a[i++] = i;

You have to hop around the standard a bit to get the full story on this but the standard (to me ) suggests that you would expect a warning, not an error.

But, as the behavior is undefined, it's not something you should ever do.

You'll need a C compiler expert (not me) to explain the philosophy behind what gets to be an error and what is just undefined.

But I don't see much of a problem here, the answer to the interview question is simple enough, it's undefined behavior (with a nice clear example in the standard) so you shouldn't do it.

MK

The compiler doesn't require consistence as its undefined behavior. Optimizations may or may not change behavior as well. You could try other compilers to see what you get, it may be different. Still, you should never code like that.

Or ask the authors of Turbo C, if their 25+year old compiler has a bug or not

It doesn't make sense trying to decipher the behaviour of a 25 year old out of support compiler surely?

Maybe I'm missing something.......

If you did about inside C which I have done a few times.. the standard K&R says I= I++ + I++ ok but not realy. here's what is allowed i = i++ + b++ is valid on its face and is repeatable. as i is on the left side of the = this is where the value of i++ + b++ if I and b both  = 5 before now here is the funny chuck of it:

we all know 5 + 5 = 10 right so after the assignment i becomes 10 right?

then I and b are both incremented. which become 6 + 6 but whatever happened to the poor i on the left side of the = is it 10 or 11 which state takes precedence over the other? you see the BNF will only get you so far you also need the "state table" and thats where that info is. Nobody talks about the State Table.

Question? if this  (i=i++ + i++) posable why couldn't you do this ( i =+i  + i++)    ??????????/

One more nail for the coffin. The big problem is if you look at the BNF ::= i++ = i++ + i++

it doesn't really mean that you use the variable i in all three spots i just means variable. the problem with assignments where the same variable is on both sides is problematic.   take a look at this: i = i + 1 this could be rewritten as i =+i which tells the compiler to (right hand first) increment  i and then store it in i,  this itself could just be i++ or could it nope, but you could do this i++ = i but you that is the compilers state table will become confused. as most of the time using the same variable on both sides of an assignment statement like a = a; what up with that? the problem is that there is something called an lvalue. Basically, any named object that persists beyond a single expression is an lvalue. So by using the same lvalue on both sides of the assignment statement, you can get some bizarre results.  The problem lies in the finite state machine. that takes your input tokenizes it and determines what to do next. To show you I will use a simple c statement.  return ( a+b ); seems innocuous at first. heres what goes on. 

1 reads: return finds that it is a keyword. checks bnf to find out whats next

2. ' ' white space; this is ignored by C

3. ( Optional (statement to follow)

4. ' ' white space; this is ignored by C

5.  a followed by + means this is a statement. get the value for a from the Data Dictionary.

6. +  this is a standard C operator "ADD" BNF::= <i>[+]<i>

7  b  this is a variable (and was expected) get the value from the Data Dictionary.

8. ' ' white space; this is ignored by C

9. ) Close paren.

10. ; end of line.

The compiler on the second or third pass puts the value of the addition of the two lvalues a, b on the stack and returns you will note that the return is not a lvalue. as it is transitory,  or temporary.

Very interesting discussion but overall doesn't yield much useful information, mostly just fun to read about all the contributors opinions and self-reflective expertise.  I've been writing embedded code since the 80's in FORTRAN IV, FORTRAN77, PASCAL, MODULA-2, C, C++, and Assembly for way to many architectures and I still wouldn't consider myself an expert (I did have to write a Modula2 compiler during my masters project capstone).  But all that being what it is, the code presented here is kind of an Obfuscated code project rather than what you would see in a commercially supported/maintained project.  You can find other eccentric coding examples at  https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest.  More to the point of this original question, you can step through the statement using the 'C Operator Precedence' rules and determine the answer a compliant compiler would generate yourself.  That would cover the expression evaluation itself but not the language semantics/adherence. A 24 year old compiler, you would have to dig out the operator precedence rules that applied for that compiler.

Just for the fun of it though, I did put this code into a GCC compiler:

arm-oe-linux-gnueabi-gcc (GCC) 5.3.0

Copyright (C) 2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

To see what it said, it doesn't generate a syntax error but it does generate a warning:

warning: operation on 'i' may be undefined [-Wsequence-point]

     x= ++i + ++i + ++i;   // i becomes 5 then 6 added becomes 11 and then incremented to 12 so 11+12=23  

                       ^

warning: operation on 'i' may be undefined [-Wsequence-point]

This warning is tell you the code has undefined semantics because of violations of sequence point rules in the C and C++ standards, so it isn't a syntax error but it is telling you that you may spend a long time debugging a problem that you could easily avoid.

But hey, if you are trying to win the Obfuscated Code Coding contest maybe that is what you want...

/Jim

C isn't really in the running for obfuscation:

From the Wiki page on APL:

The following function "life", written in Dyalog APL, takes a boolean matrix and calculates the new generation according to Conway's Game of Life. It demonstrates the power of APL to implement a complex algorithm in very little code, but it is also very hard to follow unless one has advanced knowledge of APL.

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} 

MK

Interesting, I've not seen Dyalog APL before   I still get amazed at the C stuff out there (https://www.ioccc.org/2018/burton1/hint.text ):

char O,o[];main(l){for(;~l;O||puts(o))O=(O[o]=~(l=getchar())?4<(4^l>>5)?l:46:0)?-~O&printf("%02x ",l)*5:!O;}

Actually, I avoid looking for stuff like this because it makes my hair fall out and I'm not ready to be bald yet LOL --  no really, I"m not bald yet!

James, you are on the right track and a good try.. And you actually ran the silliness. BUT to no avail, you did not understand the error message. The compiler got confused and ran home. And puff you have the error/warning message and it tells you 'i' is undefined, well not really. Debugging is not an option.

  In the 'data table' where all the variables are stored you have one instance of 'i', yes you can do a=a++; (not advised) better just use the increment operator a++; the problem as I said before is with <statement> while i = i + 1; says i equals  the value of i and add one to i and then store the new value of i back to i;   This is better i++; it says whatever is in i increment it. The problem is when you try this stunt i = i + i; which <statement>'s BNF seams to alow but can't be performed as you run into the confusion of "who is on first" (Abbot and Costello), or in other words who is 'i' this state is undefined (not valid syntactically) and therefore uncompilable.

.