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

David Brown <david.brown@hesbynett.no> writes:

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.

 If it requires that long a line of reasoning to prove that uint8_t is
*very probably* an appropriate byte type, why not just use unsigned
char, which is guaranteed to be an appropriate byte type?
 If you like, you can add:
      #if CHAR_BIT != 8
     #error "Nope"
     #endif
 When I'm writing C, "byte" doesn't mean 8 bits.  It means CHAR_BIT bits.