Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@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 23:50:43 -0700
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <vs0844$15t1k$1@dont-email.me>
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> <87tt7g7tqx.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 26 Mar 2025 07:50:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a4eec8a2f4b4f841a55717fcbf2df836";
	logging-data="1242164"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189ACY3XeLOEpKywOxb3KtLliiCMda9n64="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jyujIAbIcZeYgRh9PNRirVcXBrU=
In-Reply-To: <87tt7g7tqx.fsf@nosuchdomain.example.com>
Content-Language: en-US
Bytes: 4846

On 3/25/2025 1:14 PM, 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?
> 
> 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.
> 

Ditto.