Live data from Hacker News

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

gynvael.coldwind.pl

241–246 of 246 posts

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

#241

Earlier quoted context omitted.

The UB comes from how C++ standard defines expression sequencing which is not relevant for Java. Languages other than C++ typically define such details more strictly so there is no UB or even concept of UB. JIT compilers don't change it as any non toy JIT will generate native instructions directly or through intermediate representation (instead of generating C++ text and passing that through regular C++ compiler) bot…

late to this but what i meant was the JIT Compiler had to be compiled by a compiler at some point so its behavior is defined by the compiler used to compile it (this goes all the way down to the poor soul who hand compiled the first compiler). I'm assuming things like JIT are platform dependent and therefore the compiler used to build it would also be platform dependent. So the JIT on different platforms could have b…

The compiler is compiled via java nowadays. It's bootstrapped.

Yes the first one was probably written in C, however long ago. Not super relevant now though.

JVM/JRE, probably a different story

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

#242

I had to fight through school and university in India with my teachers who believed these were legit questions to ask in written exams. Can't 100% blame them since almost all standard-issue textbooks had them and claimed they'd give predictable output. I thought the same until I noticed the weirdness when running them across different compilers and after I read about UB, sequence points and similar quirks in books th…

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

A specific number.

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

#243

Earlier quoted context omitted.

It's worse than that, the behavior of the entire program is unconstrained by the language standard beforehand too. Raymond Chen discusses how things can go wrong once you're going to reach UB even before you get to it: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63... Anyway, I didn't mean to imply that things behaved as written aside from ordering issues. I only meant that this sort of principle can he…

> It's worse than that, the behavior of the entire program is unconstrained by the language standard beforehand too. Raymond Chen discusses how things can go wrong once you're going to reach UB even before you get to it Heh, yes that's exactly what I was thinking when I put roughly speaking . > where a kind C compiler might just mess with your numbers a bit, an evil C compiler can legally make demons fly out of your…

Apparently signed integer overflow UB helps with loop optimizations because it makes it easy to prove the loop always terminates. I assume that's not why it's UB, though; surely it's UB because some systems trapped on overflow, or produced different results due to using 1's complement, and the optimization side of the rule was a happy accident. There's a lot of history in this language and it really shows.

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

#244
post #178

Earlier quoted context omitted.

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?"

If they're wasting time during an interview on nonsense like that, nah.

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

#245

Earlier quoted context omitted.

> It's worse than that, the behavior of the entire program is unconstrained by the language standard beforehand too. Raymond Chen discusses how things can go wrong once you're going to reach UB even before you get to it Heh, yes that's exactly what I was thinking when I put roughly speaking . > where a kind C compiler might just mess with your numbers a bit, an evil C compiler can legally make demons fly out of your…

Apparently signed integer overflow UB helps with loop optimizations because it makes it easy to prove the loop always terminates. I assume that's not why it's UB, though; surely it's UB because some systems trapped on overflow, or produced different results due to using 1's complement, and the optimization side of the rule was a happy accident. There's a lot of history in this language and it really shows.

> Apparently signed integer overflow UB helps with loop optimizations because it makes it easy to prove the loop always terminates

I tried googling but couldn't find hard numbers on the performance impact of GCC's -fwrapv flag. As you'd imagine, it forces wrapping for overflowing arithmetic on signed integer types. [0]

I also have to wonder how instructive that would be anyway. The GCC devs presumably don't prioritise the performance impact of that flag. If the C language mandated it, they might find other ways to achieve similar optimisation.

This page [1] looks at the related flag for trap-on-signed-overflow, and found an impact of very roughly 6%.

See also: John Regehr's posts on this topic. [2][3] He dislikes Java's implicit wrap behaviour, as it's rarely what the programmer wants to happen. Java programmers almost never use the addExact method, [4] as it's so syntactically clumsy.

> surely it's UB because some systems trapped on overflow, or produced different results due to using 1's complement, and the optimization side of the rule was a happy accident

Per this StackOverflow answer [5] I think you have it right.

[0] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

[1] https://danluu.com/integer-overflow/

[2] https://blog.regehr.org/archives/1401

[3] https://blog.regehr.org/archives/1154

[4] https://docs.oracle.com/en/java/javase/25/docs/api/java.base...

[5] https://stackoverflow.com/a/18195756

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

#246
post #190

Earlier quoted context omitted.

> I'll wager you assumed all compilers process this line in the same way You would lose that wager. What I mean by "I do know the answer" is that I know that this is undefined behavior and why it is undefined behavior and that different compilers can give different results and also that even if I test the compiler I use to see what it does I can't count on that not changing any time the compiler gets updated.

Fair, but that was not clear to me that that's what you meant. It's clear that others interpreted it the way you intended too (since there are multiple replies saying exactly what you said) but I also don't think I'm the only one who misinterpreted. Sorry that I did.

Seems fitting in a thread about undefined behavior
Post reply on HN