Int a = 5; a = a++ + ++a; a =? (2011) • Hacker News Board

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#171

Post by zeroq » Fri, May 15, 2026, 1:33 AM UTC

kentm wrote: post #23

susam wrote: post #5

The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. 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 co…

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.

On one hand I've been using almost the exact statement 25 years ago in my Flash (ecmascript) tutorials to narrow down the point of operator precedence.

I still believe it's a good piece on your powerpoint if you want to teach. It's easy to fall, easy to grasp, and easy to unroll all the rules - that is, if the rules are actually set in stone.

On the other hand I've been through couple FAANG interviews, and twice I was presented with something similar and after I glanced at it for a half a minute the interviewer quickly proceed to "a ha!, you don't know! the interview is over , but I'm happy to tell you the right answer".

That part is not cool.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#172

Post by stevefan1999 » Fri, May 15, 2026, 1:35 AM UTC

As a guy who writes compiler the answer for this is it depends on the type of parser you are using.

LL and LR parser generates different derivation, and as such it is deterministically non-deterministic, hence UB.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#173

Post by koliber » Fri, May 15, 2026, 1:51 AM UTC

If a behavior is undefined, the theoretical answer to this could be anything, including -123, 500, or 0. We are just lucky that the compilers choose a more sane version of undefined behavior in practice.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#174

Post by daemin » Fri, May 15, 2026, 1:54 AM UTC

AnimalMuppet wrote: post #71

wat10000 wrote: post #61

Earlier quoted context omitted.

I'd say it's more like C was designed from really dumb compilers on really diverse hardware. The standard, at least the early versions of it, was more to codify what was out there than to declare what was correct. For most things like this in the standard, you can point to two pre-standardization compilers that did it differently.

Kind of both? There were pre-standard compilers, but when they created the standard, they tried to make it so that one could write really dumb compilers and still fulfill the standard.

I suspect it was also the case that if they didn't make it easy for platform vendors to implement compilers then they wouldn't do it.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#175

Post by daemin » Fri, May 15, 2026, 2:00 AM UTC

AlotOfReading wrote: post #41

Aardwolf wrote: post #15

Earlier quoted context omitted.

But this is not valuable if doing so results in different numerical results, and I think that will always happen if ++ is executed at different times, there's no point in a compiler optimizing pointless code that can silently give different results elsewhere

Your compiler does many optimizations that break numerical reproducibility, especially in floats. I reviewed a PR the other day that wrote X=A B+(C D)+E; And when I checked 3 different compilers, each of them chose a different way to use FMAs. Even with integer math, you can get different numerical results via UB (e.g. expressions with signed overflow one way and not another).

Floating point reproducibility and cross platform determinism requires strict adherence to the IEEE standard and disabling of fused instructions.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#176

Post by daemin » Fri, May 15, 2026, 2:06 AM UTC

stevefan1999 wrote: post #172

As a guy who writes compiler the answer for this is it depends on the type of parser you are using. LL and LR parser generates different derivation, and as such it is deterministically non-deterministic, hence UB.

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.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#177

Post by saghm » Fri, May 15, 2026, 2:23 AM UTC

rtpg wrote: post #158

saghm wrote: post #20

Earlier quoted context omitted.

Honestly, having increment in expressions rather than a statement feels like more of a footgun than a benefit. Expressions shouldn't mutate things.

int d = foo ? bar() : baz(); I think if anything people have been leaning more and more into expressions over statements, because when everything is an expression you end up being able to walk the gradient of complexity a bit more nicely than when you end up with a thing that just has to be broken down to a bunch of statements.

Expressions are nice specifically because they don't tend to mutate things. The ternary operator is not at all the same as `a++` because you have the assign the result.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#178

Post by nine_k » Fri, May 15, 2026, 2:31 AM UTC

everyone wrote: post #133

susam wrote: post #5

The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. 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 co…

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

Maybe the interviewer seeks to hear something like "This is UD, this code needs to be rewritten, should not pass code review. What prevents you from using -Wall when compiling?"

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#179

Post by Chaosvex » Fri, May 15, 2026, 3:11 AM UTC

el_pollo_diablo wrote: post #111

IshKebab wrote: post #88

Earlier quoted context omitted.

They don't really. In fact there are many things that are technically UB but are so common that compilers can't really treat them as UB. E.g. type punning via unions.

Type punning via unions is not UB in C in general, but it is in C++ IIRC. I write "in general" because, as with other forms of memory reinterpretation (memcpy or copy through a character type), evaluating a trap representation triggers UB.

The short version is that it's fine in C++ as long as you only read the member that was last written to or a char type.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#180

Post by jibal » Fri, May 15, 2026, 3:39 AM UTC

gynvael wrote: post #72

Boxxed wrote: post #14

> The interesting thing here is the Undefined Behavior (UB), well... actually two UBs, thanks to which there are three possible correct answers: 11, 12 and 13. No, if you invoke undefined behavior any result at all is possible.

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 p…

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

No, you're simply wrong. UB means that anything can happen. And from a security perspective, that is vital to understand.

The only proper response to this code (or similar UB due to ambiguous sequence points) if found in production is to rewrite it and fire or reeducate the author.

Sorry, but some people just aren't competent.