Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gynvael.coldwind.pl

Post reply on HN
Print view View original

11–20 of 246 posts

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

#11

Post by AlotOfReading »

Aardwolf wrote: post #7

What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…

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.

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

#14

Post by Boxxed »

> 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.

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

#15

Post by Aardwolf »

AlotOfReading wrote: post #11
Aardwolf wrote: post #7

What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…

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…

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

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

#19

Post by compiler-guy »

With undefined behavior, a conforming compiler can do anything it wants at all, including generating a program that segfaults or something else.

But what often happens in practice is that "Bill's Fly-By-Night-C-Compiler-originally-written-in-the-mid-nineties" implemented it in some specific way (probably by accident) and maintains it as a (probably informal) extension. And almost certainly has users who depend on it, and can't migrate for a myriad of reasons. Anyway, it's hard to sell an upgrade when users can't just drop the new compiler in and go.

At the language level, it is undefined-behavior, and any code that relies on it is buggy at the language level, and non-portable.

Defining it would make those compiler non-conforming, instead of just dependent on defining something that is undefined.

Probably the best way forward is to make this an error, instead of defining it in some way. That way you don't get silent changes in behavior.

Undefined behavior allows that to happen at the language level, but good implementations at least try not to break user code without warning.

Modern compilers with things like UBSan and such makes changing the result of undefined behavior much less of an issue. But most UB is also, "No diagnostic required", so users don't even know they have in their code without the modern tools.

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

#20

Post by saghm »

marcosdumay wrote: post #9
Aardwolf wrote: post #7

What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…

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.

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