What does x++ + ++x print in C? It’s one of the most common C interview questions — and the only correct answer is: nothing you can rely on. Modifying the same variable twice without a sequence point between the modifications is undefined behavior. The C standard doesn’t just leave the result unspecified — it makes no guarantee the program behaves sensibly at all. This page walks through the question from our C Programming Quiz App, shows what real compilers actually do with this code, and explains the sequence point rules behind it.
The Quiz Question
int x = 5;
printf("%d", x++ + ++x);
What is printed by this code?
- 11
- 12
- 13
- Undefined behavior
The Correct Answer: Undefined Behavior
x is modified twice in a single expression — once by x++ and once by ++x — with no sequence point between the two modifications. The C standard (C11 §6.5p2) says that if a side effect on a scalar object is unsequenced relative to another side effect on the same object, the behavior is undefined. Not “compiler-dependent”, not “unspecified” — undefined, meaning the standard permits literally any outcome.
Both major compilers warn about this line the moment you enable warnings:
$ gcc -Wall -Wextra quiz.c
quiz.c:5:21: warning: operation on 'x' may be undefined [-Wsequence-point]
5 | printf("%d\n", x++ + ++x);
| ~^~
$ clang -Wall quiz.c
quiz.c:5:21: warning: multiple unsequenced modifications to 'x' [-Wunsequenced]
On our test machines, both gcc 13.3 (Ubuntu 24.04) and Apple clang 21 happened to print 12 — but “happened to” is the key phrase. A different optimization level, compiler version, or architecture is free to print 11, 13, or anything else, and the program would still be equally “correct” as far as the standard is concerned.
Why Each Wrong Answer Seems Right
The three numeric options are all defensible hand-traces — which is exactly why the question is a trap. Each assumes an evaluation order the standard never promises:
Why not 11?
Trace: read x for x++ (5), read x for ++x before any increment lands (5 + 1 = 6), sum = 11. This assumes both reads happen before either write — a legal machine-code ordering, but only one of several.
Why not 12?
Trace: x++ yields 5 and bumps x to 6, then ++x makes it 7 and yields 7 — wait, that’s 12 via 5 + 7. Or: ++x first makes x=6 and yields 6, then x++ yields 6; 6 + 6 = 12. Two different orderings that coincidentally agree — and the value we actually observed on both gcc and clang. Observing 12 doesn’t make 12 the answer; it makes 12 one possible symptom.
Why not 13?
Trace: ++x first (x=6, yields 6), then x++ yields 6 but its increment is applied before the addition reads it as 7. Contrived? Yes. Forbidden? No — once behavior is undefined, the “as-if” rule no longer protects you.
What Is a Sequence Point in C?
A sequence point is a point in program execution where all side effects of previous evaluations are guaranteed to be complete. Between two consecutive sequence points, the compiler may evaluate sub-expressions in any order — and if your code modifies the same variable twice in that window, there is no “right” order to appeal to.
The main places C guarantees a sequence point:
- At the end of a full expression (the
;) - After the left operand of
&&,||, and,(comma operator) - After the condition in
? : - After all function-call arguments are evaluated, before the call itself
Note what’s not in the list: +. The two operands of an addition are unsequenced relative to each other. Writing the same variable in both operands is the textbook violation.
The safe rule of thumb: never modify a variable twice in one expression, and never modify and separately read it in one expression. If you need the value before and after an increment, use two statements — the code becomes trivially correct and dramatically more readable:
int old = x; /* 5 */
x += 2; /* one clear modification */
printf("%d", old + x); /* well-defined: 12, everywhere, forever */
How to Catch This Bug
gcc -Wall -Wextra file.c # -Wsequence-point flags it at compile time clang -Wall file.c # -Wunsequenced flags it at compile time
Both compilers catch this class of bug at compile time with normal warning flags — one more reason -Wall -Wextra should be on every build. (Runtime UBSan does not flag sequence-point violations; this one is caught by static warnings.)
Frequently Asked Questions
Is x++ + ++x a compile error in C?
No. It compiles — with a warning if warnings are enabled. Undefined behavior is a runtime concept: the compiler is allowed to accept the code and produce anything at all when it runs.
Why do gcc and clang both print 12 if it’s undefined?
Coincidence of implementation, not a guarantee. Both compilers happen to apply the increments in an order that yields 12 on x86-64 today. A future version, different optimization flag, or different target may print something else without violating the standard.
Is x = x + 1 + x++ also undefined?
Yes. Any expression that modifies x while also reading or modifying it elsewhere without an intervening sequence point is undefined — including x = x++, a[i] = i++, and f(x, x++).
Related Reading
- Increment and Decrement Operators in C
- Arithmetic Operators in C
- C Aptitude Questions and Answers
- Pointers in C – Complete Guide
Recommended Books
- The C Programming Language – Kernighan & Ritchie (India) | Amazon.com
- C Programming: A Modern Approach – K.N. King (India) | Amazon.com
This question is #7 in the C Programming Quiz App — 155 questions with explanations covering operators, pointers, memory, and more.
Download on Google Play →