The program fragment: int a = 5, b = 2; printf("%d", a+++++b);

Concept

A C lexer scans the source text using the maximal munch (longest match) rule: at every position it consumes the longest sequence of characters that forms a valid token before moving on. Separately, the postfix increment operator ++ is only defined when its operand is a modifiable lvalue (a named, assignable object) — it can never be applied to the value produced by another expression such as a++.

Application

1. Scan a+++++b left to right. After the identifier a, five consecutive '+' characters remain before b.

2. Apply maximal munch at each step: the first two '+' form the token ++, the next two '+' form a second ++, and the single remaining '+' is left as +. The token stream is therefore a ++ ++ + b.

3. Parse this stream: the first ++ binds to a as a postfix increment (a++), producing a's old value as a temporary result and scheduling a to be incremented.

4. The second ++ must now attach to whatever immediately precedes it, i.e. the result of a++. That result is a temporary value, not a modifiable lvalue, so the compiler cannot apply increment to it and reports a constraint violation (an 'lvalue required' diagnostic) at compile time.

Cross-check

Contrast this with the well-known shorter case a+++b, which tokenizes as a ++ + b — a single valid postfix increment on a followed by ordinary addition with b, so it compiles and evaluates cleanly. The extra pair of '+' signs in a+++++b is exactly what breaks this pattern: it forces a second increment onto a non-lvalue, which no standard C compiler accepts.

Result: because the statement fails to compile, it never outputs 7, 8, or 9 — the program's actual behaviour is that compilation fails and nothing is printed.