Hacker News Reader

Comment by torstenvl | Hacker News Reader

Congratulations on inventing slower one's complement.

> I’d like to have . . . a 63 bit unsigned integer. . . . However, it is undefined behavior if it ever stores a negative value.

No. There is no "debug mode" for undefined behavior. Undefined behavior is always undefined behavior.

It also doesn't "automatically come[] with a precondition that it cannot be negative" - only that if it's ever negative, your program might crash for reasons that cannot be found in your code.

If you really want this, use uint64_t and treat any value over 0x7fffffffffffffff as an error.

Curious about the drive-by downvoters: Can you point out where you think I'm wrong?

View on HN

> Undefined behavior is always undefined behavior.

This is not true; the standard explicitly allows implementations to, and I quote directly from the standard, "behave during translation or program execution in a documented manner characteristic of the environment".

This idea that undefined behavior is always undefined behavior and there's no way to reason about it is purely academic, incorrect, and not in any way justified either by source material or in practice.

As for debugging undefined behavior, UBSan [1] is an excellent tool that is well supported by GCC and clang, and MSVC is working to add support for it as well.

[1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

of course the standard allows implementations to "behave during translation or program execution in a documented manner characteristic of the environment" if you do something that is undefined behavior, implementations are literally allowed to do anything they want if you do something that is undefined behavior. the key point is that they are not required to do anything, so what's the point of adding more undefined behavior for this case?

The subtle distinction is that when the standard specifies that behavior is undefined, it does not mean that an implementation is forbidden from providing well specified and documented semantics, and hence the statement I replied to "Undefined behavior is always undefined behavior" is false and furthermore a common misconception.

The point of adding more undefined behavior for this case, or any case in general, is to provide optimization opportunities that do not require introducing changes to the syntax (such as additional type checking or analysis). That way a C++ compiler is welcome to provide debugging support and various checks when a program is compiled in debug mode, and then eliminate those checks and make very strong assumptions about the program's runtime behavior when a program is compiled with optimizations enabled.

This is in contraposition to OPs claim that "There is no "debug mode" for undefined behavior.". There absolutely is a debug mode and it absolutely can catch undefined behavior, and UBSan is an excellent tool for doing precisely what OP claimed is not permissible in C++.

63 bit integers are actually used in Ocaml which is then used to figure out if a value is a integer or a pointer

https://blog.janestreet.com/what-is-gained-and-lost-with-63-...

Also used in Ruby virtual machines and no doubt many others.

63-bit integers with undefined behavior for negatives do not exist in OCaml.

No but the thing is that the 64th bit will cause undefined behavior if it is set incorrectly, it will cause a interger to be seen as a pointer instead of a number. That was the reason I thought about it.

torstenvl is correct. UB is UB whether you are in debug mode or release mode. making it UB for it to store a negative value doesn't make sense. you could put debug checks for it behind an if constexpr or a macro but please C++ has enough UB already, don't add more. disappointing to see that this is downvoted.

Reply on news.ycombinator.com