5 ms·

I would guess that the reasoning (which I agree with) is that defined signed overflow precludes a standards-compliant compiler both from making certain optimiza

I would guess that the reasoning (which I agree with) is that defined signed overflow precludes a standards-compliant compiler both from making certain optimizations (made under the assumption that overflow will not occur) and from performing error checking (e.g. -ftrapv), and enables the writing of confusing code (which unsigned arithmetic would make more clear). Forced to choose, I'd rather see signed overflow be required to abort the program or throw an exception than wrap.

kazinator 8y ago
That's bad for code that can handle overflow and do something reasonable, like switch to bignum integers. If wrapping takes place, overflow can be detected in-line; no funny control paths via exceptions or whatever. Without the spectre of UB hanging over overflows, efficient code for dealing with overflows can also be ISO-defined at the same time.
- colanderman 8y ago
  > That's bad for code that can handle overflow and do something reasonable, like switch to bignum integers. I see that as an argument for throwing exceptions or setting a flag on overflow, not for silently wrapping to negative values. Defining signed overflow means that I can't enable runtime checking of it without erroneously flagging intended cases of overflow. To deny that to support the tiny percentage of developers who write bignum libraries strikes me as a poor tradeoff. (Simply checking for a sign change isn't sufficient for implementing bignums anyway. It's trivially possible to multiply a large positive number by a small positive number and have it wrap not only past negatives back to positives, but to a number larger than the input.)
int_19h 8y ago
The next best thing would be for C++ to adopt something like Zig's modulo-wraparound operators: +% -% *% /%. Writing a proper implementation of signed overflow in portable C++ is annoyingly complicated right now, for something that can be useful so often. Or better yet, some way to specify an expression context for all arithmetic operators contained inside - the default could still be undefined, but you could then also explicitly request wraparound, saturation, or fast-fail. Something like C# checked(), basically (which gives you fast-fail), but covering all useful cases. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/checked-and-unchecked https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- pjmlp 8y ago
  I bet there is already something like that available as library.
  - int_19h 8y ago
    There is, e.g.: https://github.com/dcleblanc/SafeInt https://github.com/dcleblanc/SafeInt But IMO something like this should be a language thing, just so that it's not substantially harder or more verbose to use operators with explicit wraparound or trap.
    - pjmlp 8y ago
      What we need is a winner in the C++ package manager wars, then adding such dependencies wouldn't be such a big issue.

kazinator 8y ago

That's bad for code that can handle overflow and do something reasonable, like switch to bignum integers. If wrapping takes place, overflow can be detected in-line; no funny control paths via exceptions or whatever. Without the spectre of UB hanging over overflows, efficient code for dealing with overflows can also be ISO-defined at the same time.

colanderman 8y ago
> That's bad for code that can handle overflow and do something reasonable, like switch to bignum integers. I see that as an argument for throwing exceptions or setting a flag on overflow, not for silently wrapping to negative values. Defining signed overflow means that I can't enable runtime checking of it without erroneously flagging intended cases of overflow. To deny that to support the tiny percentage of developers who write bignum libraries strikes me as a poor tradeoff. (Simply checking for a sign change isn't sufficient for implementing bignums anyway. It's trivially possible to multiply a large positive number by a small positive number and have it wrap not only past negatives back to positives, but to a number larger than the input.)

int_19h 8y ago

The next best thing would be for C++ to adopt something like Zig's modulo-wraparound operators: +% -% *% /%. Writing a proper implementation of signed overflow in portable C++ is annoyingly complicated right now, for something that can be useful so often. Or better yet, some way to specify an expression context for all arithmetic operators contained inside - the default could still be undefined, but you could then also explicitly request wraparound, saturation, or fast-fail. Something like C# checked(), basically (which gives you fast-fail), but covering all useful cases. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/checked-and-unchecked https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

pjmlp 8y ago
I bet there is already something like that available as library.
- int_19h 8y ago
  There is, e.g.: https://github.com/dcleblanc/SafeInt https://github.com/dcleblanc/SafeInt But IMO something like this should be a language thing, just so that it's not substantially harder or more verbose to use operators with explicit wraparound or trap.
  - pjmlp 8y ago
    What we need is a winner in the C++ package manager wars, then adding such dependencies wouldn't be such a big issue.