2

I tested this on different machine and on different compiler, but I gave out the same output:

int sum = 10, i = 5;
printf("%d", sum+++i);

Is this well-defined or undefined behavior in C?

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
Kevin Dong
  • 5,001
  • 9
  • 29
  • 62
  • 1
    Please search for "maximum munch" on Stack Overflow, and you'll find plenty of duplicates. – Lundin Nov 18 '14 at 10:49
  • @KerrekSB It _was_ closed for the right reason. It got 1 confused duplicate vote by someone else, then dupe hammer by yours sincerely. Maybe this is a site design mistake, it should only show the duplicate which gets most votes. – Lundin Nov 18 '14 at 11:01
  • Related to [Why doesn't a+++++b work in C?](http://stackoverflow.com/q/5341202/1708801) – Shafik Yaghmour Nov 18 '14 at 14:02
  • @george-stocker I think that duplicte is a pretty poor question, it is basically a confusion over how post-increment works which by today's standards is off-topic and I would personally close it as such. This [question](http://stackoverflow.com/q/5649354/1708801) is actually much closer and [this question](http://stackoverflow.com/q/5341202/1708801) is also not a bad more general fit either, I would choose to close it as both if that is possible. – Shafik Yaghmour Nov 18 '14 at 15:00
  • @ShafikYaghmour Thanks; fixed. I'm not a C++ expert, so my goal was to set things to how they were. It was confusing to follow all the threads. – George Stocker Nov 18 '14 at 19:52

2 Answers2

12

It's well defined. sum+++i is parsed as sum++ + i, which results as 15 (with the side effect of incrementing sum).

C11 §6.4 Lexical elements

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

And a similar example is followed:

EXAMPLE 2 The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression.

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
  • 1
    May I know where you got this information? (+1 TOP answer :D) – Rizier123 Nov 18 '14 at 10:43
  • 2
    @YuHao: The point is, this program is well-defined even if you never compile it. Even if you wrote it on paper on a lonely island, it would be well formed C with predictable semantics. Why rob us of this insight? – Kerrek SB Nov 18 '14 at 10:46
  • 1
    @KerrekSB Good point. I'll edit the post not to blame the compiler :) – Yu Hao Nov 18 '14 at 10:49
  • @Rizier123 It's quoted from the C standard. You might be interested in [Where do I find the current C or C++ standard documents?](http://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents) – Yu Hao Nov 18 '14 at 13:47
5

This statement

printf("%d", sum+++i);

corresponds to

printf("%d", sum++ + i);

and is a well-formed statement. There is no any undefined behaviour.

The output will be 

15

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.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335