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

Quentin Colombet via llvm-dev
Tue, 11 Jun 2019 21:33:03 -0000

> On Jun 11, 2019, at 12:59 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
<mailto: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?”

+1

>
>
> On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de
<mailto: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 <mailto: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/20190611/c5ce3ffc/attachment.html>