multiple pre increment/post increment in expression of C language

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