--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!

Meredith Montgomery <mmontgomery@levado.to> writes:
> --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!

The intN_t types are almost certainly, for a given implementation,
defined as typedefs for one of the predefined signed integer types
(signed char, short, int, long, long long). In almost all existing
implementations, all those types use a 2's-complement representation
with no padding bits. (The few implementations for non-2's-complement
systems, as far as I know, don't even support C99 and are not likely to
in the future.)

An implementation that uses 1s'-complement or that has padding bits
simply wouldn't define the intN_t types (unless it's able to emulate
the required features).

The predefined types are mandatory, so the standard has to be a bit
flexible about representation to avoid making implementations for exotic
systems impractical. The intN_t and uintN_t types are optional, and are
defined only if the implementation can support them.

The [u]int_leastN_t and [u]int_fastN_t types do not require
2's-complement, and are mandatory for all conforming implementations for
N = 8, 16, 32, 64.

The next edition of the C standard is likely to mandate 2's-complement
for signed integer types. Padding bits are still a theoretical issue,
as are sizes other than the usual 8, 16, 32, 64.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> The intN_t types are almost certainly, for a given implementation,
> defined as typedefs for one of the predefined signed integer types
> (signed char, short, int, long, long long).
[...]

I wrote "almost" because they could also be implemented in terms of
extended integer types. I'm not aware of any implementation that even
has extended integer types.

But for example, an implementation with 8-bit char, 16-bit short, and
64-bit int and long might define int32_t as a typedef for an extended
32-bit type.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 1/26/22 19: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!

You're correct. The size-named types are likely to be typedefs for
standard types, but they're not required to be - they could be typedefs
for extended integer types. Keep in mind that the exact-sized types are
all optional. The only size-named types that are mandatory are the least
and fast versions, and only for 8, 16, 32, and 64 bits.
Since C2011, you can test for this: _Generic() checks for compatible
types, so you find _Generic() accepting 'int' as a match for 'int32_t',
you'll know that it meets those requirements too.

You can have a fully conforming implementation of C on almost any
platform, as a matter of deliberate design, and one of the key things
that makes that true are the things like this that aren't mandatory.

As a practical matter you're seldom going to run into non- two's
complement platforms, which is why C++ has made it mandatory, and why C
may be heading in the same direction.

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.)