4 ms·

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 s

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?

Kranar 4y ago
> 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 https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
- deleted 4y ago
  [deleted]
- jeffffff 4y ago
  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?
  - Kranar 4y ago
    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++.
erk__ 4y ago
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-bit-integers/ https://blog.janestreet.com/what-is-gained-and-lost-with-63-...
- torstenvl 4y ago
  63-bit integers with undefined behavior for negatives do not exist in OCaml.
  - erk__ 4y ago
    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.
- deleted 4y ago
  [deleted]
- matheusmoreira 4y ago
  Also used in Ruby virtual machines and no doubt many others.
jeffffff 4y ago
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.

Kranar 4y ago

> 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 https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

deleted 4y ago
[deleted]
jeffffff 4y ago
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?
- Kranar 4y ago
  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++.

erk__ 4y ago

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-bit-integers/ https://blog.janestreet.com/what-is-gained-and-lost-with-63-...

torstenvl 4y ago
63-bit integers with undefined behavior for negatives do not exist in OCaml.
- erk__ 4y ago
  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.
deleted 4y ago
[deleted]
matheusmoreira 4y ago
Also used in Ruby virtual machines and no doubt many others.

jeffffff 4y ago

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.