Space as a token its impact on evaluation of binary or unary operator

Question

I being wondering the tokens and how they are evaluated by the compiler, But I never considered space as a essential token for making a statement valid syntactically,

For example.

#include<stdio.h>
int main(){

        int first=1,second=3;
        int res=first+++++second;
        printf("%d \n",res);
        return 0;
}

Gives the following error:

rough3.c:7:17: error: lvalue required as increment operand int res=first+++++second;

But by simply appending a " " between two postfix (++) and prefix (++) seems to work fine.

#include<stdio.h>
int main(){

        int first=1,second=3;
        int res=first++ + ++second;
        printf("%d \n",res);
        return 0;
}

Works fine prints value 5. I have looked into this question rather then undefined behavior I want to know :
When does compiler decides that spaces between expression are redundant or not?
What happens when we take precedence and associativity together to evaluate these expressions?

See the ["Maximal Munch"](https://en.wikipedia.org/wiki/Maximal_munch) rule. — molbdnilo, Mar 03 '17 at 13:05
This is a duplicate. The question was asked earlier this week and closed as a duplicate of other questions. — Jonathan Leffler, Mar 03 '17 at 13:09
@JonathanLeffler A canonical duplicate does indeed exist. Closed. — Lundin, Mar 03 '17 at 13:35

Vlad from Moscow · Answer 1 · 2017-03-03T15:02:39.017

According to the C Standard (6.4 Lexical elements)

4 If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token. There is one exception to this rule: header name preprocessing tokens are recognized only within #include preprocessing directives and in implementation-deﬁned locations within #pragma directives. In such contexts, a sequence of characters that could be either a header name or a string literal is recognized as the former.

Thus for this declaration

int res=first+++++second;

if the input stream has been parsed into preprocessing tokens up to the name first then the next longest preprocessing token after the identifier first is ++

int res=first++ +++second;
             ^^

Then the next longest preprocessing token is again ++

int res=first++ ++ +second;
             ^^ ^^

and so on.

So these tokens will be produced

int res=first++ ++ + second ;
             ^^ ^^ ^ ^^^^^^ ^

According to the C grammar this declaration is considered like

int res= (first++)++ + second;

And the compiler issues an error because the expression (first++) is not an lvalue. So the postfix operator ++ may not be applied to the expression.

The second case compiles successfully because white space though itself is not a token acts as a separator among tokens hence the evaluation occurs in following order. `int res=first++ + ++second;` and compiles without an error. :) — OldMontMonk, Apr 15 '17 at 06:15

score 2 · Accepted Answer · edited Mar 03 '17 at 13:11

2

int res=first+++++second;

is interpreted as

int res = (first++)++ +second;

hence the compilation error because (first++) is not an l-value.

but

int res=first++ + ++second;

is interpreted as

int res = (first++) + (++second);

which is correct.

edited Mar 03 '17 at 13:11

Jean-François Fabre

137,073
23
153
219

answered Mar 03 '17 at 13:05

Jabberwocky

48,281
17
65
115

don't you like those `++++++++` questions ? – Jean-François Fabre Mar 03 '17 at 13:11
thanks for the answer :). – OldMontMonk Mar 03 '17 at 13:15

Space as a token its impact on evaluation of binary or unary operator

2 Answers2