Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164670
| 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> |
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 | Next — Previous in thread | Find similar | Unroll 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