Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #164670

Re: C99: 7.18.1.1 Exact-width integer types

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: C99: 7.18.1.1 Exact-width integer types
Date 2022-01-27 09:14 +0100
Organization A noiseless patient Spider
Message-ID <sstka1$ef9$1@dont-email.me> (permalink)
References <86k0emc9ga.fsf@levado.to>

Show all headers | View raw


On 27/01/2022 01:24, Meredith Montgomery wrote:
> --8<---------------cut here---------------start------------->8---
> 7.18.1.1 Exact-width integer types
> 
> 1. The typedef name intN_t designates a signed integer type with width
> N, no padding bits, and a two's complement representation.  Thus,
> int8_t denotes a signed integer type with a width of exactly 8 bits.
> --8<---------------cut here---------------end--------------->8---
> 
> It seems C99 garantees that these nice integers types will use two's
> complement.  But I guess we have no such guarantee for int or char?
> It's only for intN_t.  Can you share your experience on this?  Thank
> you!
> 

Others have given the formal details.  I'd just like to point out a
couple of other details.

While you will almost guaranteed never see a machine that does not use
two's complement signed integers without padding (except for the _Bool
type, which is a little special), there /are/ current processors that
don't have 8-bit char and therefore won't have int8_t or uint8_t.  These
are mostly DSP or other niche and specialised embedded processors, but
they do exist and will do so for the foreseeable future.  However,
you'll know if you are writing code for such devices, and the overlap
between code for these and code for other types of processors is very
small - it is very rare for code to have to run on both.

Another point that is sometimes misunderstood is that even when an
integer type is guaranteed to be two's complement, signed integer
arithmetic overflow is /not/ defined in C.  You don't get "two's
complement wrapping" on overflow, even with types that are defined as
two's complement representation.

(When the C++ committee voted to require two's complement signed integer
representation for C++20, they explicitly rejected the idea of defining
overflow behaviour.  I expect the C committee to follow the same
principle for the next C standard, probably C23.)

Back to comp.lang.c | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

C99: 7.18.1.1 Exact-width integer types Meredith Montgomery <mmontgomery@levado.to> - 2022-01-26 21:24 -0300
  Re: C99: 7.18.1.1 Exact-width integer types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-26 16:48 -0800
    Re: C99: 7.18.1.1 Exact-width integer types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-26 17:02 -0800
  Re: C99: 7.18.1.1 Exact-width integer types James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-26 21:32 -0500
  Re: C99: 7.18.1.1 Exact-width integer types David Brown <david.brown@hesbynett.no> - 2022-01-27 09:14 +0100

csiph-web