[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
Aaron Ballman via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 11 23:55:03 PDT 2019
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.
> On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de>
>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev