[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 Spencer via llvm-dev]

On Tue, Jun 11, 2019 at 1:00 PM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Jun 11, 2019 at 12:24 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>> I agree that readability, maintainability, and ability to debug/find
>> issues are key.
>> I haven't found myself in a situation where unsigned was helping my
>> readability: on the opposite actually I am always wondering where is the
>> expecting wrap-around behavior and that is one more thing I have to keep in
>> mind when I read code that manipulate unsigned. So YMMV but using unsigned
>> *increases* my mental load when reading code.
>>
> I'm on the other end.  I'm always reading the code wondering "is this
> going to warn?"  "Why could a container ever have a negative number of
> elements?"  "The maximum value representable by the return type (unsigned)
> is larger than that of the value i'm storing it in (signed), so an overflow
> could happen even if there were no error.  What then?"
>
>
> On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de>
> wrote:
>
>> Am Di., 11. Juni 2019 um 11:45 Uhr schrieb Zachary Turner via llvm-dev
>> <llvm-dev at lists.llvm.org>:
>> >
>> > 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?
>

sequence containers (like vector) cannot hold more items than a ptrdiff_t
(a signed type) can represent due to requirements based on std::distance.

I don't see a use for unsigned types outside of bit manipulation.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190611/d25372bb/attachment-0001.html>