On 01/07/2025 22:57, Thiago Macieira via Std-Proposals wrote:
> On Tuesday, 1 July 2025 11:06:31 Pacific Daylight Time Sebastian Wittmeier via
> Std-Proposals wrote:
>> AFAIK std::byte and uint8_t are different beasts.
>
> Right, uint8_t is only a byte for CHAR_BIT == 8 platforms (see other thread).
> Otherwise, the byte type is unsigned char, for which we provide an enum
> wrapper with the same size.
>

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__)));

I don't know why it was done this way - perhaps the result was better
code generation for the target (the AVR has always been a bit odd in
gcc, and had limited developer resources for the backend, so this could
have been a shortcut to save effort in the code generator backend).

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

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


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.