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

[David Greene via llvm-dev]

+1.

                     -David

Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> writes:

> I have not chimed in on the general signed/unsigned discussion, but my experience porting software to various embedded systems and game consoles over the
> years has taught me to always prefer using explicitly sized integer types except where size_t should be used.
>
> While it is generally true that most modern 64-bit architectures all agree on the meanings of `short`, `long`, `unsigned`, `int`, and others. There is no guarantee of
> that. I would strongly support a coding standard that suggested preferring explicitly sized integer types (i.e. int64_t) over `int`.
>
> -Chris 
>
>  On Jun 14, 2019, at 6:40 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>  -----Original Message-----
>  From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF
>  Bastien via llvm-dev
>  Sent: Thursday, June 13, 2019 12:25 PM
>  To: John Reagan
>  Cc: llvm-dev at lists.llvm.org
>  Subject: 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."
>
>  On Jun 13, 2019, at 9:19 AM, John Reagan <john.reagan at vmssoftware.com>
>
>  wrote:
>
>  Yes.  We currently build LLVM 3.4.2 on our OpenVMS Itanium box with an
>  older EDG/Intel C++03 compiler to create legacy cross-compilers to our
>  OpenVMS x86 box (well, VirtualBox).  We do have a few tweaks to the
>  relocations to access static data always through the GOT (including
>  CodeGen's static data).  Our linker sees references to code (which might
>  be in 64-bit space) and creates trampolines in 32-bit space.  That lets
>  any legacy code from the VAX-days to continue to take the address of a
>  routine and save it into some INTEGER*4 Fortran variable.
>
>  So mostly a small memory model with a few things from medium/large.
>
>  I've been unable to build the companion clang 3.4.2 however as its use
>  of templates seems to push our old compiler over the edge of sanity.
>
>  We're working on bootstrapping 8.0.0.  Compile 8.0.0 on Linux, move
>  objects to our OpenVMS Itanium box to use the cross-linker (which can
>  handle Linux objects as well as our own), move the resulting image to
>  our OpenVMS x86 box...  (and the same thing for libcxx, compiler-rt,
>  libcxxabi, etc.) and with a wave of a magic wand, we end up with a
>  native clang.  And with a little more waving, our other legacy compilers
>  (our C, BLISS, Pascal, COBOL, BASIC, and Fortran)
>
>  I'm planning on submitting a lightning talk for this fall on "When 3
>  memory models isn't enough.”
>
>  This is a rare occurrence… but you leave me speechless. I don’t even know
>  where to start.
>
>  The word-size migration is rare but not unique.  The HP/Tandem NonStop
>  line has moved from 16-bit to 32-bit to 64-bit over the decades, and we
>  needed to handle mixed-size pointers and "int" weirdness at each stage.  
>  OpenVMS is a special snowflake in terms of its LLVM bootstrapping process, 
>  and the mind just boggles at what John and his team have had to contend 
>  with. But the size part is certainly familiar to me, and actually simpler
>  than what NonStop had to deal with. (We weren't using LLVM, clearly, but
>  container size etc. is not a particularly LLVM-specific issue.)
>  --paulr
>
>  On 6/13/19 12:00 PM, JF Bastien wrote:
>
>  On Jun 12, 2019, at 2:01 PM, John Reagan via llvm-dev <llvm-
>
>  dev at lists.llvm.org> wrote:
>
>  On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de>
>  wrote:
>
>  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?
>
>  That's not true on my platform.  I have 64-bit pointers so intptr_t is
>  64-bits, but the largest thing you can allocate is only 32-bits big so
>  size_t (and ptrdiff_t) are 32-bits.
>
>  It runs LLVM?
>
>  _______________________________________________
>  LLVM Developers mailing list
>  llvm-dev at lists.llvm.org
>  https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>  _______________________________________________
>  LLVM Developers mailing list
>  llvm-dev at lists.llvm.org
>  https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev