3 ms·

The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many pr

The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many previously implementation-defined programming patterns strictly conforming, but is it true? Doesn't seem mentioned in the Twitter thread.

rwmj 5y ago
This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?
- gallier2 5y ago
  The AGC (Apollo Guidance Computer). This means we won't go to the moon anytime soon ;-)
- qsort 5y ago
  Some microcontrollers used to have saturating arithmetic, which is basically the only other behavior that makes any sense.
  - MaxBarraclough 5y ago
    Perhaps I'm missing something obvious, but isn't that orthogonal to representation? You could implement saturating arithmetic for any representation scheme, no?
    - tomsmeding 5y ago
      You can only observe whether the representation is 2s-complement or not if you can see what wrapping does.
      - MaxBarraclough 5y ago
        That doesn't sound right. You can use the union trick in C (but not C++, strictly speaking) to read the bit-pattern of a signed integer as an unsigned integer, for example. [0] Overflow of signed integer types remains undefined behaviour in both C and C++. A compiler is free to make a promise like signed integer overflow is always handled with wrapping or signed integer overflow is always handled with saturation. (GCC has a flag, -fwrapv, to enable guaranteed wrapping. [1]) [0] https://stackoverflow.com/a/25664954/ https://stackoverflow.com/a/25664954/ [1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
- MaxBarraclough 5y ago
  > Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code? I think such machines are pretty much a thing of the past. This topic cropped up in a 2018 thread when C++ made the same change. [0] [0] https://news.ycombinator.com/item?id=17190864 https://news.ycombinator.com/item?id=17190864
- Findecanor 5y ago
  The devil is not in the number representation but in the details. The proposal says: > Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals. This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception. In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided. The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction. But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.
  - pascal_cuoq 5y ago
    The sentence you quote is near to the words: “[The C++ standardization committee] WG21 has recently adapted the changes promoted in their document p12363. Generally, C++ goes much beyond what is presented here:” I would be extremely surprised if the proposal to make signed arithmetic overflow defined behavior in C made it into C23. The window is narrowing and this would be a very big change to the language. Making it official that 2's complement is the only representation for signed integers is already a large change. Later in the decade, maybe.

rwmj 5y ago

This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

gallier2 5y ago
The AGC (Apollo Guidance Computer). This means we won't go to the moon anytime soon ;-)
qsort 5y ago
Some microcontrollers used to have saturating arithmetic, which is basically the only other behavior that makes any sense.
- MaxBarraclough 5y ago
  Perhaps I'm missing something obvious, but isn't that orthogonal to representation? You could implement saturating arithmetic for any representation scheme, no?
  - tomsmeding 5y ago
    You can only observe whether the representation is 2s-complement or not if you can see what wrapping does.
    - MaxBarraclough 5y ago
      That doesn't sound right. You can use the union trick in C (but not C++, strictly speaking) to read the bit-pattern of a signed integer as an unsigned integer, for example. [0] Overflow of signed integer types remains undefined behaviour in both C and C++. A compiler is free to make a promise like signed integer overflow is always handled with wrapping or signed integer overflow is always handled with saturation. (GCC has a flag, -fwrapv, to enable guaranteed wrapping. [1]) [0] https://stackoverflow.com/a/25664954/ https://stackoverflow.com/a/25664954/ [1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
MaxBarraclough 5y ago
> Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code? I think such machines are pretty much a thing of the past. This topic cropped up in a 2018 thread when C++ made the same change. [0] [0] https://news.ycombinator.com/item?id=17190864 https://news.ycombinator.com/item?id=17190864
Findecanor 5y ago
The devil is not in the number representation but in the details. The proposal says: > Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals. This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception. In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided. The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction. But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.
- pascal_cuoq 5y ago
  The sentence you quote is near to the words: “[The C++ standardization committee] WG21 has recently adapted the changes promoted in their document p12363. Generally, C++ goes much beyond what is presented here:” I would be extremely surprised if the proposal to make signed arithmetic overflow defined behavior in C made it into C23. The window is narrowing and this would be a very big change to the language. Making it official that 2's complement is the only representation for signed integers is already a large change. Later in the decade, maybe.