Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?)
Date: Tue, 25 Mar 2025 13:14:30 -0700
Organization: None to speak of
Lines: 63
Message-ID: <87tt7g7tqx.fsf@nosuchdomain.example.com>
References: <vrd77d$3nvtf$2@dont-email.me> <868qp1ra5f.fsf@linuxsc.com>
	<vrdhok$47cb$2@dont-email.me> <20250319115550.0000676f@yahoo.com>
	<vreuj1$1asii$4@dont-email.me> <vreve4$19klp$2@dont-email.me>
	<20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com>
	<vrh1br$35029$2@dont-email.me> <LRUCP.2$541.0@fx47.iad>
	<vrh71t$3be42$1@dont-email.me> <vrh9vh$3ev9o$1@dont-email.me>
	<vrhct4$3frk8$2@dont-email.me> <20250320204642.0000423a@yahoo.com>
	<vrhphb$3s62l$1@dont-email.me>
	<87iko3s3h2.fsf@nosuchdomain.example.com>
	<vrrvgp$1828d$1@dont-email.me>
	<874izi82a4.fsf@nosuchdomain.example.com>
	<vrttin$321rm$1@dont-email.me> <20250325092315.416@kylheku.com>
	<vrusai$3rlfi$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 25 Mar 2025 21:14:32 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7cb379057f60c5676f5334e6c65b06bf";
	logging-data="89421"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+mT6lb6Mh4njzCHVxFnxhd"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:sMMcS673UyzOqSH2WmDahw2fOiw=
	sha1:LbOnGIcG78uYP6Pgyv5CDAJeK04=
Bytes: 4735

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */