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

On 25/03/2025 21:14, Keith Thompson wrote:

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?
 

Perhaps I was not clear in my argument above.
If "uint8_t" is /not/ an appropriate type for a typedef "byte", then there are /no/ appropriate choices for a typedef of that name.
"unsigned char" is always an appropriate type for a typedef "c_standard_byte" - but not necessarily for what the majority of programmers - C programmers or otherwise - see as a "byte".
The problem is that the C standards use an obscure, non-standard and potentially confusing definition of the normal, standardised computer science term "byte".  If code is going to use the word "byte" at all, it should be used in the sense that is standard for the most important people involved - the human programmers - while not conflicting with the C definition of the term.  If the target does not support a type that acts like a "byte" in the common programming sense /and/ in the C standards sense, then it is a mistake to use the word "byte" at all in the code.

If you like, you can add:
      #if CHAR_BIT != 8
     #error "Nope"
     #endif
 

I prefer not to clutter my code with such unnecessary checks - I use "uint8_t", knowing that it has a built-in compile-time check that CHAR_BIT is 8, and that it explicitly says exactly what I intend it to say.
I accept that this reduces the portability of my code.  For one thing, it is not portable to targets that have CHAR_BIT > 8.  That's fine - if I am working with a target with CHAR_BIT > 8, I know that I am working on such a target.
And within compilers with CHAR_BIT == 8, my code is also limited in portability to real-world compilers.  I don't see that as a hinder, at least for the work I do.
(Of course I don't complain if some header for an Arduino typedef's byte as "unsigned char" - I already know that the target device has 8-bit char, and that it will work as I expect.)

When I'm writing C, "byte" doesn't mean 8 bits.  It means CHAR_BIT bits.
 

It's worth remembering that you are in the tiny fraction of C programmers who think that way.  "Normal" C programmers can, do, and arguably should assume that CHAR_BIT is always 8.
But that's okay.  Different programmers do different kinds of work, and can and should make different choices and assumptions.