On Wednesday, 2 July 2025 02:00:30 Pacific Daylight Time David Brown via Std-
Proposals wrote:
> std::byte also has different allowed operations from uint8_t and
> unsigned char.
>
> And while uint8_t is typically an alias for "unsigned char", it does not
> have to be - on the standard library for the AVR port of gcc, it was
> defined as:
>
> typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));

That's not actually different. It's a different spelling of "unsigned char"
because in C++ it mangles the same:
https://gcc.godbolt.org/z/86rvT7fMM

> It is also possible for implementations to make uint8_t an extended
> integer type, though I don't think any compilers do that.

True.

> And if the target does not support a suitable type for uint8_t, then the
> type won't exist at all.
>
> So uint8_t and unsigned char can be different types (as the standard
> currently stands), and std::byte is a separate type (an enum class with
> unsigned char as the underlying type).

And while uint8_t and unsigned char can be different types, if both exist then
they are of the same size and have the same number of bits. That's a
consequence of the definition of both: C++ requires unsigned char to be at
least 8 bits wide because it must be able to hold the UTF-8 code units (since
C++11), and uintNN_t requires no padding bits. Therefore, if uint8_t exists,
it's necessarily the smallest of the uintNN_t.

> Thus when some people make "u8" an alias for "unsigned char", others for
> "uint8_t", or "uint_fast8_t", or "uint_least8_t", enforcing a particular
> interpretation could lead to subtle changes in existing code.

Though if the CHAR_BIT == 8 paper gets adopted, then uint_least8_t becomes
obsolete: the type that has at least 8 bits is the type that has exactly 8
bits.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering