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

[Renato Golin via llvm-dev]

+1 to both points here.

On Wed, 12 Jun 2019, 07:55 Aaron Ballman via llvm-dev, <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Tue, Jun 11, 2019, 9:59 PM Zachary Turner <zturner at roblox.com> 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?"
>>
>
> Strong +1 to this.
>
> ~Aaron
>
>
>>
>> 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?
>>
>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190612/8fd6c45d/attachment.html>