IMO, The only reasonable answer if asked this in an interview is “I would not write code where I have to know the answer to this question”

These sorts of things are neat trivia to learn about things like sequence points but 99.9% of the time if it matters in your codebase you're writing something unmaintainable.

In some sense, and without the interviewer knowing, that is actually a great scenario for an interview.

If you can convince someone in a position of authority that they’re wrong about something technical without upsetting them then you’re probably a good culture fit and someone who can raise the average effectiveness of your team.

Do you want a job at a place where someone who doesn't understand UB makes the hiring decisions?

Genuinely curious, so this is undefined behavior and depends on the compiler. I get that. Java, and other languages, can do these same operations but their compilers produce bytecode that runs on a virtual machine (JVM) compiled to machine code just-in-time. Would this same code in Java possibly yield different results based on the platform the JVM was running on because of the platform specific JIT compiler? Maybe that's part of the origin of the phrase "write once, test everywhere".

> I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the correct answer.

Other than the job for most programmers having nothing to do with whether they know the outcome, because hopefully they'd never write something like it or clean it up. And IF they found it they'd hopefully test it - given that it appears to be compiler dependent anyways.

Both major compilers yell at you for this nowadays... it's pretty unforgivable IMHO for somebody to be asking it as an exam or interview question if the right answer isn't "undefined":

    <source>:5:10: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
        5 |     a = a++ + ++a;
          |         


    <source>:5:7: warning: operation on 'a' may be undefined [-Wsequence-point]
        5 |     a = a++ + ++a;
          |     ~~^~~~~~~~~~~

How many tennis balls can fit in a bus?

The interviewer asking stuff like that is a good sign to leave immediately.

> I am very glad these types of interview questions have become less prevalent these days. They have, right? Right?

Are you referring to the type of interview questions where the question is ill-defined and no one should know the answer, or the type where the question is reasonable and well-defined, but the interviewer doesn't know the answer?

I had a phone screen with Google once where they asked how to determine the length of a stretch of contiguous 1s within an infinite array of 0s. I suggested that, given the starting index i, you can check the index i+2 and then repeatedly square it until you find yourself among the zeroes, after which you can do binary search to find the transition from ones to zeroes.

The interviewer objected that this will grow the candidate end index too quickly, and the correct thing to do is to check index i+1 and then successively double it until you find the zeroes. We moved on.

I passed that phone screen. But I still resent it, because I checked the math later and "successive squaring followed by binary search" and "successive doubling followed by binary search" take exactly the same amount of time.

Heh, one time when I got this style of question[1] (but for JavaScript), I took a glance at it and said "Um ... you really shouldn't write code like that." The interviewer replied, "Oh. Yeah. Fair point." And then went on to another question.

[1] By which I mean predicting the behavior of error-prone code that requires good knowledge of all the quirks of the language to correctly answer.

>I am very glad these types of interview questions have become less prevalent these days. They have, right? Right?

I just refuse to do interviews like that any more.

Well... tried it on macOS using vanilla gcc, the results surprised me:

  $ /bin/cat x.c; gcc -w -o x x.c; ./x
  #include <stdio.h>
  
  int main()
  {
      int a = 5;
      a += a++ + a++;
      printf("a = %d\n", a);
  }
  a = 18

- The first a++ expression results in 5, after a = 6 - The second a++ expression results in 6, after a = 7 - Only then the LHS a is evaluated for the addition-assignment, so we get: a = 7 + 5 + 6 = 18

The short answer is because C was designed to give leeway to really dumb compilers on really diverse hardware.

This isn't quite the same case, but it's a good illustration of the effect: on gcc, if you have an expression f(a(), b()), the order that a and b get evaluated is [1] dependent on the architecture and calling-convention of f. If the calling convention wants you to push arguments from right to left, then b is evaluated first; otherwise, a is evaluated first. If you evaluate arguments in the right order, then after calling the function, you can immediately push the argument on the stack; in the wrong order, the result is now a live variable that needs to be carried over another function call, which is a couple more instructions. I don't have a specific example for increment/decrement instructions, but considering extremely register-poor machines and hardware instruction support for increment/decrement addressing modes, it's not hard to imagine that there are similar cases where forcing the compiler to insert the increment at the 'wrong' point is similarly expensive.

Now, with modern compilers using cross-architecture IRs as their main avenue of optimization, the benefit from this kind of flexibility is very limited, especially since the penalties on modern architectures for the 'wrong' order of things can be reduced to nothing with a bit more cleverness. But compiler developers tend to be loath to change observable behavior, and the standards committee unwilling to mandate that compiler developers have to modify their code, so the fact that some compilers have chosen to implement it in different manners means it's going to remain that way essentially forever. If you were making a new language from scratch, you could easily mandate a particular order of evaluation, and I imagine that every new language in the past several decades has in fact done that.

[1] Or at least was 20 years ago, when I was asked to look into this. GCC may have changed since then.

Sethi-Ullman register allocation reorders subexpression evaluation to achieve efficient register allocation: https://dl.acm.org/doi/10.1145/321607.321620

With modern register allocators and larger register sets, code generation impact from following source evaluation is of course lower than it used to be. Some CPUs can even involve stack slots in register renaming: https://www.agner.org/forum/viewtopic.php?t=41

On the other hand, even modern Scheme leaves evaluation order undefined. It's not just a C issue.

Applying the increment or decrement operators over the same variable more than once on the same line should be a compile-time error.

Anyway, yes, this one example has an obvious order it should be applied. But still, something like it shouldn't be allowed.

It's valuable for compilers to be able to choose the instruction scheduling order. Standards authors try not to unnecessarily bind implementors. If post increment happened after the full statement is finished, then the original value has to be maintained until the next sequence point. Maybe the compiler will be smart enough to elide that, maybe not, but it's a lot more difficult to fix those kinds of edge cases than to say sequencing is undefined.

The C standard doesn't define things where two or more historical compilers disagreed and there wasn't an obviously correct way. This is defined behavior (left to right, assignment last) in Java, which is a different language.

Probably because when C was standardised there were already multiple implementations, and this was an area where implementations differed but it wasn't viewed as important enough to bring them in line with one approach.

The only other reasonable option is to make such garbage a compile time error. There is no reasonable definition of what code like that should do and if you write it in the real world you need find better job fit. I'd normally say McDonald's is hiring, but they don't want people like that either

> What's the reason that C didn't define the order of this?

The OP article provides experimental details but annoyingly does not give the big picture w.r.t. C language specifications (provided in the links though).

There are three concepts at interplay here which is at the root of the problem; 1) Expressions (evaluates to a single value) 2) Statements (tells computer to perform an action) and 3) Sequence Points (specific moment during execution when all previous side-effects are guaranteed to be complete).

It is the sequence points during the evaluation of expressions which is important to understand here. From https://en.wikipedia.org/wiki/Sequence_point;

In C and C++, a sequence point defines any point in a computer program’s execution at which it is guaranteed that all side effects of previous evaluations will have been performed, and no side effects from subsequent evaluations have yet been performed. They are a core concept for determining the validity of and, if valid, the possible results of expressions...

1) An expression's evaluation can be "sequenced before" the evaluation of another expression. (Equivalently, the other expression's evaluation can be "sequenced after" that of the first.)

2) The expression's evaluation is "indeterminately sequenced", meaning that one is "sequenced before" the other, but which is unspecified.

3) The expression's evaluation is "unsequenced", meaning the operations in each expression may be interleaved.

The "Order of Evaluation" states; (from https://en.cppreference.com/c/language/eval_order)

"Order of evaluation of the operands of any C operator, including the order of evaluation of function arguments in a function-call expression, and the order of evaluation of the subexpressions within any expression is unspecified (except where noted below)."

The "Single Update Rule" states; (from https://www.accellera.org/images/eda/sv-bc/0282.html)

Between consecutive "sequence points" an object's value can be modified only once by an expression. The C language defines the following sequence points:

       Left operand of the logical-AND operator (&&).
       Left operand of the logical-OR operator (||).
       Left operand of the comma operator.
       Function-call operator.
       First operand of the conditional operator.
       The end of a full initialization expression.
       The expression in an expression statement.
       The controlling expression in a selection (if or switch) statement.
       The controlling expression of a while or do statement.
       Each of the three expressions of a for statement.
       The expression in a return statement.

For more detailed explanations, see Angelika Langer's Sequence Points and Expression Evaluation in C++ - https://angelikalanger.com/Articles/VSJ/SequencePoints/Seque...

> What's the reason that C didn't define the order of this?

I didn't open TFA but my first thought was "Is this even defined?".

It kinda make sense that suck fucktardedness could be not defined.

It's defined. And called "operator precedence", both post/pre-increment have a higher precedence than the single "+".

At least according to this: https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Exp...

I think the main confusion here comes from the fact that "a" is just a value, not a pointer, where it matters when the value/address which the pointer points at is accessed (before of after the increment of the pointer's own 'value').

Anyway… my C skills are rusty. Maybe I get it wrong. :) In any case I always would use brackets to avoid any ambiguity in constructs like this.

But what answer did they expect? A specific number or that it's UB?

Hey! Author here :)

So let me start by saying that that blog post was written was 15 years ago and I don't even remember the details of it and what I've written there. But, I have a hot-take on this topic you've touched on!

From a programmer perspective, you are absolutely right. The behaviour is undefined, end of discussion. A programmer should never rely on what they observe as the effective behaviour of an UB. A programmer must avoid creating situations in code that could result in the execution flow venturing into the areas of UB. And - per C and C++ standards - results of UB can be anything (insert the old joke about UB formatting one's disk being a formally correct behaviour).

However, I'm a security researcher, and from the security point of view - especially on the offensive side - we need to know and understand the effective behaviours of UBs. This is because basically all "low-level" vulnerabilities in C/C++ are formally effects of UBs. As such, for the security crowd, it still makes sense to investigate, understand, and discuss the actual observed effects of UBs, especially why a compiler does this, what are the real-world actual variants of generated code (if any) for a given UB for this and other compilers, how can this be abused and exploited, and so on.

My point being - there are two sides to this coin.

I feel we need another category - unspecified behavior. I think everyone would agree the compiler should putout ONE of those answers and that nasal demons would be out of spec.

The problem is that it’s not specified which should be picked, but all pick something.

> including generating a program that segfaults or something else.

UB = run nethack or Emacs:

https://feross.org/gcc-ownage/

We should have kept this behaviour. It would make UB a lot more unpalatable and easy to find.

Yeah, like left-to-right as in JS for example.

Hey! Author here :)

I'm going top-to-bottom through comments, and there was a similar question, so I'll link my answer here: https://news.ycombinator.com/item?id=48140821 (TL;DR: you are right, but there's another perspective on this)

I also started doing this. I feel that "b = expr(a); a++;" expresses what I mean better than "b = expr(a++)": store expr(a) in b, then store a+1 in a. Any good compiler will optimize the same.

After separating a++ onto its own line, replacing a++ with a+=1 or a=a+1 comes down to personal taste in syntax sugar. I vote for a+=1.

Awk also says it's 12.

  awk 'BEGIN{a=5; a = a++ + ++a; print a}'
  12

Out of curiosity, I checked if gcc would optimize i = i++ out, and it does!

"Test Your C Skills" is a published book by Yashavant Kanetkar, apparently published in 2005, and still available in paperback. The document you linked to appears to be a scan of a printed copy of that book, and is almost certainly in violation of copyright. The cover and the title and copyright pages are notably missing.

Although Rust doesn't have either ++ increment operator, it does have both the assignment = and the add-assign += and they're both expressions because almost everything in Rust is an expression.

Crucially however these expressions have the unit type () aka the empty tuple as their result, ruling out hard to follow C like int a = 1 + (b = 2 + (c = d * 3));

Similarly the "Oops I wrote = instead of ==" gets so rare as to be negligible when you stop coercing everything to a boolean. In Rust only true is true and only false is false. So when you write if k = 5 rather than checking if k == 5 that's a type error. The expression k == 5 is a boolean, that would be fine, but the expression k = 5 is just () and that's neither true nor false it's just the wrong type.

But you can still change the parser to output the expression in the AST (or otherwise) so it is evaluated left to right or right to left. Just that doing it in a way that is not natural for the algorithm will require extra code.

Your code:

    int a = 5;
    int b = a++;

Giving 13 for a++ + ++a is not a bug in the compiler. It's a bug in the code.

The correct answer to "what does a++ + ++a do" is "it gets rejected in code review and replaced with code that expresses the actual intent.

The trick here is that the original expression contains undefined behavior. Your example does not.

Are you volunteering to update all the code that would be broken?

This is true. What's also true, is that if that smart name works in cybersec, they'll feel right at home :)

(this is related to my other comment here https://news.ycombinator.com/item?id=48140821)

Godbolt: clang and gcc compilers give 12. msvc compilers yield 13.

    #include <stdio.h>

    int main() {
        int a = 5;
        a = a++ + ++a;
        printf("%d\n", a);
        return 0;
    }

    example.c
    ASM generation compiler returned: 0
    example.c
    Execution build compiler returned: 0
    Program returned: 0
    13

    ASM generation compiler returned: 0
    Execution build compiler returned: 0
    Program returned: 0
    12

    <source>:5:10: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
        5 |     a = a++ + ++a;
          |          ^    ~~
    1 warning generated.
    ASM generation compiler returned: 0
    <source>:5:10: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
        5 |     a = a++ + ++a;
          |          ^    ~~
    1 warning generated.
    Execution build compiler returned: 0
    Program returned: 0
    12

If the behavior is undefined, there is no wrong result.

The nice thing about these is that all answers are correct.