← Back to context

Comment by umanwizard

8 hours ago

Signed overflow being UB (while unsigned is defined to wrap) is a quirk of C and C++ specifically, not some fundamental property of computing.

Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern.

  • Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.

  • Back when those machines existed, UB meant "the precise behaviour is not specified by the standard, the specific compiler for the specific machine chooses what happens" rather than the modern "a well-formed program does not invoke UB". For what it is worth, I compile all my code with -fwrapv et. al.

Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.

  • Presumably unsigned want to return errors too?

    Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything.

  • > making basic types work differently from C would involve major performance costs.

    Not if you compile with optimizations on. This C code:

      int wrapping_add_ints(int x, int y) {
          return (int)((unsigned)x + (unsigned)y);
      }
    

    Compiles to this x86-64 assembly (with clang -O2):

      wrapping_add_ints:
              lea     eax, [rdi + rsi]
              ret
    

    Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics.