5 ms·

> Well naive signed integer subtraction can be UB as well. Sure, but the point is that you have to get overflow due to high magnitude of the involved integers.

> Well naive signed integer subtraction can be UB as well. Sure, but the point is that you have to get overflow due to high magnitude of the involved integers. So yeah INT_MAX - -INT_MAX is UB, but you have to have quantities up around INT_MAX for this to be a problem. For the unsigned case you just have to have quantities around 0. Now, having quantities around INT_MAX isn't necessarily that unusual, but what seals the deal for me (I wrote that SO answer) is that 64-bit values are becoming more ubiquitous, and there we can guarantee in some sense that many quantities won't reach their 2^63 limits any time soon. So I definitely thing "signed by default" is much more of a slam dunk if it is paired with "64-bit by default". Note that though I'm a proponent of signed by default, in practice I find it hard to write this way in C and C++ because you are constantly fighting the impedance mismatch between the language, size_t, size(), etc and your own rule. So signed by default is definitely more palatable in languages which made that same decision for their builtins and standard library.

jart 5y ago
> So I definitely thing "signed by default" is much more of a slam dunk if it is paired with "64-bit by default". Yes yes and yes. There is nothing that would make me happier than if GCC and Clang gave us the freedom to choose an ILP64 data model. In that case, we wouldn't need prototypes anymore and we could restore much of the original intent behind the design of C.
gpderetta 5y ago
FWIW, I think these days unsigned size(), although something that conceptually makes sense, is generally considered a mistake although not something that the committee can easily fix.
- deleted 5y ago
  [deleted]
- nyanpasu64 5y ago
  In C++, if I use unsigned variables whenever possible, the users get an invariant for free that these indexes are never negative (though C++ has no overflow checking to catch "negative" overflowing values at time of creation). Would a language with signed sizes and indexing lose out on this property, and require data structure and algorithmic/business logic to compulsively check all outside input to ensure these values are non-negative (because negative values are in the type's domain, but invalid for many algorithms)? What about compulsively checking internal state (which may/not have the intended and/or enforced invariant that internal state values are non-negative)?
  - gpderetta 5y ago
    As discussed elsethread, out of bounds unsigned integers are as wrong as negative indices. And checking for positive and in bound is no more expensive than checking for just within bounds. The only issue with negative indices is that it is no longer possible to have containers-of-bytes as large as the address space, but except for that tiny time window when an usable 4GB address space was actually available on 32 bits systems, it is in practice not a big restriction.

jart 5y ago

> So I definitely thing "signed by default" is much more of a slam dunk if it is paired with "64-bit by default". Yes yes and yes. There is nothing that would make me happier than if GCC and Clang gave us the freedom to choose an ILP64 data model. In that case, we wouldn't need prototypes anymore and we could restore much of the original intent behind the design of C.

gpderetta 5y ago

FWIW, I think these days unsigned size(), although something that conceptually makes sense, is generally considered a mistake although not something that the committee can easily fix.

deleted 5y ago
[deleted]
nyanpasu64 5y ago
In C++, if I use unsigned variables whenever possible, the users get an invariant for free that these indexes are never negative (though C++ has no overflow checking to catch "negative" overflowing values at time of creation). Would a language with signed sizes and indexing lose out on this property, and require data structure and algorithmic/business logic to compulsively check all outside input to ensure these values are non-negative (because negative values are in the type's domain, but invalid for many algorithms)? What about compulsively checking internal state (which may/not have the intended and/or enforced invariant that internal state values are non-negative)?
- gpderetta 5y ago
  As discussed elsethread, out of bounds unsigned integers are as wrong as negative indices. And checking for positive and in bound is no more expensive than checking for just within bounds. The only issue with negative indices is that it is no longer possible to have containers-of-bytes as large as the address space, but except for that tiny time window when an usable 4GB address space was actually available on 32 bits systems, it is in practice not a big restriction.