multiple pre increment/post increment in expression of C language

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

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.

.

>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.

Actually, I do understand the message and it is a WARNING not an ERROR.  In fact, when you take this program and run it, the result is: 19.  It didn't crash and burn or go puff. It didn't complain about 'i' as undefined or anything like that, in fact, it acted just like the warning it is.  Now I'm not saying this is good programming practice or anything like that because it isn't. I don't basically disagree with what you are saying, I'm just pointing out that it isn't an error in the language spec.  In fact, if you compile the code, you get a warning, but it does generate code (this is for an ARM Cortex-A7) that then executes:

{
int i=4;
44: e3a03004 mov   r3, #4
48: e58d3004 str   r3, [sp, #4]
int x= ++i + ++i + ++i;  
4c: e59d3004 ldr   r3, [sp, #4]
50: e2833001 add   r3, r3, #1
54: e58d3004 str   r3, [sp, #4]
58: e59d3004 ldr   r3, [sp, #4]
5c: e2833001 add   r3, r3, #1
60: e58d3004 str   r3, [sp, #4]
64: e59d2004 ldr   r2, [sp, #4]
68: e59d3004 ldr   r3, [sp, #4]
6c: e0822003 add   r2, r2, r3
70: e59d3004 ldr   r3, [sp, #4]
74: e2833001 add   r3, r3, #1
78: e58d3004 str   r3, [sp, #4]
7c: e59d3004 ldr   r3, [sp, #4]
80: e0823003 add   r3, r2, r3
84: e58d3000 str   r3, [sp]
printf("x(%d) = ++i + ++i + ++i;\n",x);
88: e59d1000 ldr   r1, [sp]
8c: e3000000 movw  r0, #0
90: e3400000 movt  r0, #0
94: ebfffffe bl    0 <printf>
}

When you run this code, the result is 'x=19'.  So the code isn't 'uncompilable' because I just compiled it, it ran and produced an output.  That may not be the result you wanted or thought it should be because of the semantics associated with the sequence point rules in C and C++, but the assertion that the BNF supports your conclusion that it will not compile and result in an error is incorrect.  Different compilers all utilize different parsers in their construction--LALR, LL, SLR, GLR--and each will parse this statement differently; some may and some may-not compile the code due to the compiler writers interpretation, but I avoid blanket absolute statements.

You are correct about different parsers. But I do believe better than 70% will fail.  Even though BNF allows it  Your parser won't. I don't know why folks keep bringing this thing out of its grave. Its like a zombie it just never dies.

Oh BTW about obfuscated code. it like APL unreadable. that is  why I hate Python it like Fortran but with out line numbers.

james.flynn  wrote:

 

you can step through the statement using the 'C Operator Precedence' rules and determine the answer a compliant compiler would generate yourself. 

This really isn't right.

A compliant compiler is one which is compliant with a specified standard.

ISO/IEC 9899 ("C99"|) and as far as I know all subsequent ISO C standards specify things like:

i = ++i + 1;

a[i++] = i;

as undefined.

This means that a compiler may make any result it likes and still be compliant.

No, not really if your code is not compliant. 1 it probably not run. I know folk love to talk about it but. And even if it does run there is no guaranty the answer will be correct.

BTW the two examples you show maybe compliant. As in the first one if i started as 1 answer should be 3

in #2 you increment i after the store OK. but things like

i = i++ + i++ are illegal and not compliant as most if not all parsers (2 or 3 pass optimizing) will get very confused. (this is where we all got on this stupid train, and as for me its time to get off and do something more important.) 

At this point the discussion really is a dead horse.  I compiled the code with GCC v5.x--which is a Compliant compiler (https://gcc.gnu.org/onlinedocs/gcc/Standards.html )--so your assertion that is it illegal and not compliant is flat out wrong.

Rather than beating the horse, what I really want to highlight that people come to web-sites like element14 for primarily 2 reasons: (1) to get an answer to a question [I doubt they are going to come here to determine if their compiler is compliant] and (2) to find solutions to problems.  I responded to this thread because it is promulgating incorrect information about the compliance/legality of a correctly (though idiotic) C expression, then attempted to validate that information by incorrectly citing BNF notation.  The entire premises of the argument is invalidated by simply compiling the code segment and seeing that it does compile (though with a warning) and run.

IMO, it is wrong to disseminate incorrect information as fact when it is really opinion.