C++ Logo

std-proposals

Advanced search

Re: [std-proposals] CHAR_BIT == 8 p3635r0

From: Lénárd Szolnoki <cpp_at_[hidden]>
Date: Wed, 16 Jul 2025 11:34:46 +0100
On 1 July 2025 16:26:53 BST, Howard Hinnant via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Jul 1, 2025, at 10:03 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tue, Jul 1, 2025 at 1:12 AM Thiago Macieira via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>>
>>> On Monday, 30 June 2025 06:01:34 Pacific Daylight Time Matthew Taylor via Std-
>>> Proposals wrote:
>>>> they are permanently on C++98/03 and so there is little point in changing
>>>> how we design C++26 or C++29 to account for them.
>>>
>>> But unless the architectures themselves are end-of-lifed, we can't guess the
>>> future. There could be a point when there's a requirement from their users to
>>> update, but that can only happen if it is still possible.
>>>
>>> In any case, how does the standard change in any way by requiring 8-bit bytes?
>>
>> It's more that standardizing it would change the thinking *around* the language.
>>
>> At present, C++ could be said to consist of 2 conceptual languages:
>> the literal text of the standard, and the language "for all practical
>> purposes". There's a fair amount of stuff that one can do with C++ on
>> all "normal" implementations which is not guaranteed by the standard.
>> One of the reasons for adding things like implicit object creation is
>> to bring more of the "for all practical purposes" code into compliance
>> with the literal text of the standard.
>>
>> For all practical purposes, a byte is 8 bits, and people write code
>> every day on that assumption. But that's not what the literal text
>> says that the language is, so all of that code is hypothetically
>> implementation-dependent (but not practically). So standardizing 8-bit
>> bytes would be another step towards merging these two conceptual
>> languages.
>
>Could we make everyone happy by making the CHAR_BIT==8 guarantee opt in?
>
>Perhaps the syntax for that opt-in could be:
>
> static_assert(CHAR_BIT == 8);
>
>Oh, look, it’s already catching on: https://github.com/search?q=static_assert%28CHAR_BIT+%3D%3D+8%29&type=code
>
>:-)
>
>Howard

Can we do this opt-in for future additions to the standard library? Or are we forced to introduce an octet type unrelated to byte if we want networking in the standard?

I think requiring CHAR_BIT == 8 for hosted implementations would make sense, leaving freestanding alone. But there needs to be some proposed additions (like networking) that motivate it.

Lénárd

Received on 2025-07-16 10:34:55