[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."

Michael Kruse via llvm-dev
Wed, 12 Jun 2019 22:07:23 -0000

Am Di., 11. Juni 2019 um 14:59 Uhr schrieb Zachary Turner <zturner at
roblox.com>:
>> > I'm personally against changing everything to signed integers.
To me, this is an example of making code strictly less readable and more
confusing in order to fight deficiencies in the language standard.  I get the
problem that it's solving, but I view this as mostly a theoretical problem,
whereas being able to read the code and have it make sense is a practical
problem that we must face on a daily basis.  If you change everything to signed
integers, you may catch a real problem with it a couple of times a year.  And by
"real problem" here, I'm talking about a miscompile or an actual
bug that surfaces in production somewhere, rather than a "yes, it seems
theoretically possible for this to overflow".
>>
>> Doesn't it make it already worth it?
>
> vector.size() returns a size_t, which on 64-bit platforms can represent
types values larger than those that can fit into an int64_t.  So to turn your
argument around, since it's theoretically possible to have a vector with
more items than an int64_t can represent, isn't it already worth it to use
size_t, which is an unsigned type?

According to your definition above, this is not a "real problem".
64-bit CPUs do not support using the full 64-bit virtual address
space. Even if one does in the future, PTRDIFF_MAX (and as a
consequence std::distance that a std::vector must support) effectively
limits the max allocation size that can be worked with without
undefined behavior.

To summarize, with signed sizes we could fix a few production-bugs a
year, while unsigned sizes only have a theoretical advantage in
production.

Michael