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

Krzysztof Parzyszek via llvm-dev
Wed, 12 Jun 2019 15:04:59 -0000

> The underlying problem is that the C family of languages mixes two
orthogonal properties: value range and overflow behavior. There is no unsigned
type with undefined wraparound. So the question becomes: What property is more
important to reflect? Do we want catch unintended wraparound behavior using a
sanitizer/make optimizations based on it?

That's a valid argument, but I suspect that the vast majority of loops using
an unsigned induction variable, start at an explicit 0 and go up by 1.  Such
loops cannot overflow, so there is nothing to catch there.


--
Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Michael
Kruse via llvm-dev
Sent: Tuesday, June 11, 2019 2:26 PM
To: Zachary Turner <zturner at roblox.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Aaron Ballman <aaron.ballman
at gmail.com>
Subject: [EXT] Re: [llvm-dev] [RFC] Coding Standards: "prefer `int` for
regular arithmetic, use `unsigned` only for bitmask and when you intend to rely
on wrapping behavior."

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?


> On the other hand, a large number of people need to work in this codebase
every day, and multiplied over the same time period, my belief is that having
the code make sense and be simple has a higher net value.
>
> It simply doesn't make sense (conceptually) to use a signed type for
domains that are inherently unsigned, like the size of an object.  IMO, we
should revisit this if and when the deficiencies in the C++ Standard are
addressed.

The underlying problem is that the C family of languages mixes two orthogonal
properties: value range and overflow behavior. There is no unsigned type with
undefined wraparound. So the question becomes: What property is more important
to reflect? Do we want catch unintended wraparound behavior using a
sanitizer/make optimizations based on it?
Do we need the additional range provided by an unsigned type? As Chandler says
in one of his talks linked earlier: "If you need more bits, use more
bits" (such as int64_t).

Michael
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org