Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?)

On 25/03/2025 17:31, Kaz Kylheku wrote:

On 2025-03-25, David Brown <david.brown@hesbynett.no> wrote:

Personally, I think "typedef uint8_t byte;" /is/ ideal - and much better
than "typedef unsigned char byte;" would be.  I say that as someone who
works in a field with bits and bytes more than ints and doubles.

 The problem is that uint8_t is not endowed with the special
aliasing rules for accessing objects of other types as arrays
of unsigned char. A type called byte is prone to precipitating
into those uses.
 

The minimum size for an "unsigned char" is 8 bits.  There are no other standard integer types that are unsigned, have no padding bits, and can be 8 bits in size (except that plain "char" can be identical to "unsigned char").  "uint8_t" is a typedef of an integer type that is exactly 8 bits, with no padding.  There can be no C implementation for which "uint8_t" can exist, and for which "unsigned char" is not an appropriate choice.  No other standard integer types can possibly be suitable (except perhaps "char").
So if "uint8_t" on an implementation is /not/ a typedef for unsigned char, the implementation must be providing an extended integer type of identical size and characteristics to "unsigned char".  No known implementation of C has, to my knowledge, ever had actual extended integer types.
In order for a C implementation to provide a uint8_t type that does not have the "magic" aliasing powers of character types (now called "byte types" in C23), the implementation would have to provide an extended integer type otherwise identical to "unsigned char" except for its aliasing powers, and specifically use that for "uint8_t" contrary to normal user expectations.  I believe this is hypothetically possible, but so unrealistic as to be ignorable.  However, if you or anyone else has reason to believe it /is/ realistic, I'd appreciate hearing about it.

A platform like Arduino could assert that in their toolchain,
the type byte does have those properties (and then somehow ensure
that is true, in spite of it being uint8_t, like by patching
the compiler if they have to).
 

"uint8_t" is a typedef - not its own integer type.  If it is a typedef of "unsigned char" (as it is for the AVR gcc port, used by the Arduino), it inherits the magic aliasing powers of "unsigned char" - typedef names an alias, not a new type.