5 ms·

C++ has an absurd amount of UB to the point where there's an entire thought exercise devoted to how malicious a compliant compiler can be (Hell++.) There are th

C++ has an absurd amount of UB to the point where there's an entire thought exercise devoted to how malicious a compliant compiler can be (Hell++.) There are things that are allowed and even common in C but UB in C++ (union type punning,) and things that people reasonably can assume would work but are UB anyway (signed integer overflow.) Then you have weird edge cases like assigning the return value of a two argument std::max involving temporaries to a reference. There are so many UB foot guns, no reasonable developer can be expected to keep track of them all.

pif 2y ago
> things that people reasonably can assume would work but are UB anyway (signed integer overflow.) No, they cannot. You don't have the right to make any assumption about integer overflow in C. Most of the whining about UB is from people who still refuse to accept that you don't have the right to think about your processor family once you write in any language that is not assembly.
psini 2y ago
Cannot find any articles discussing Hell++. Is it something specific? The thought seems very interesting and I'd like to read about it if you have any links :-) Thanks!
- camblomquist 2y ago
  Honestly might just be a Discord in-joke on a C++ server as I can't find much specific either. Sorry for misleading!
- GrantMoyer 2y ago
  I'm not sure about Hell++, but DeathStation 9000 is a "common" jocular name for a hypothetical system which is as pathological as possible with respect to implementation definined and undefined behavior.
kccqzy 2y ago
> things that people reasonably can assume would work but are UB anyway (signed integer overflow.) Since when is it reasonable to assume that? > Then you have weird edge cases like assigning the return value of a two argument std::max involving temporaries to a reference You have a reference to a temporary. Reference lifetime extension is a thing. No UB there. Completely defined and supported.
- JonChesterfield 2y ago
  When all hardware built for decades uses two's complement arithmetic and even the standards bodies have noticed this (e.g. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm) it's not remotely necessary to assume that overflowing a signed integer is undefined behaviour. It's totally defined exactly what that instruction is going to do on any hardware any electrical engineer is willing to build. However, some benchmarks use iteration on a signed integer, and assuming that loop terminates makes it slightly faster, so in order to retain that marginal advantage over other languages, signed iteration shall be assumed to never overflow. This is very typical of the C++ experience.
  - f33d5173 2y ago
    That's not why it's ub. It's ub to allow compilers to optimize x*2/2 to just x. If you want overflow, you can use unsigned, which has been defined to follow 2's complement semantics for quite some time.

pif 2y ago

> things that people reasonably can assume would work but are UB anyway (signed integer overflow.) No, they cannot. You don't have the right to make any assumption about integer overflow in C. Most of the whining about UB is from people who still refuse to accept that you don't have the right to think about your processor family once you write in any language that is not assembly.

psini 2y ago

Cannot find any articles discussing Hell++. Is it something specific? The thought seems very interesting and I'd like to read about it if you have any links :-) Thanks!

camblomquist 2y ago
Honestly might just be a Discord in-joke on a C++ server as I can't find much specific either. Sorry for misleading!
GrantMoyer 2y ago
I'm not sure about Hell++, but DeathStation 9000 is a "common" jocular name for a hypothetical system which is as pathological as possible with respect to implementation definined and undefined behavior.

kccqzy 2y ago

> things that people reasonably can assume would work but are UB anyway (signed integer overflow.) Since when is it reasonable to assume that? > Then you have weird edge cases like assigning the return value of a two argument std::max involving temporaries to a reference You have a reference to a temporary. Reference lifetime extension is a thing. No UB there. Completely defined and supported.

JonChesterfield 2y ago
When all hardware built for decades uses two's complement arithmetic and even the standards bodies have noticed this (e.g. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm) it's not remotely necessary to assume that overflowing a signed integer is undefined behaviour. It's totally defined exactly what that instruction is going to do on any hardware any electrical engineer is willing to build. However, some benchmarks use iteration on a signed integer, and assuming that loop terminates makes it slightly faster, so in order to retain that marginal advantage over other languages, signed iteration shall be assumed to never overflow. This is very typical of the C++ experience.
- f33d5173 2y ago
  That's not why it's ub. It's ub to allow compilers to optimize x*2/2 to just x. If you want overflow, you can use unsigned, which has been defined to follow 2's complement semantics for quite some time.