What does non-8-bit mean? The standard demands >= 8 bits per char. Wider ALUs (>= 16 bits) are supported by short and int types. So either there are some ALU computations possible with 8 bits < size < 16 bits Or the memory is accessed with data units in those sizes. I cannot imagine any new platform having the need for such requirements and then not mapping to byte = 8 bits. Even if the standard allows, it would lead to all kind of compatibility problems of existing C++ code with that platform. Memory (even SRAM) is much cheaper to produce now than then. Special ALU sizes can be supported by intrinsics. See the very early Nvidia CUDA GPUs with 24 bit integer multiplications. But they quickly switched to 32 bits. They did not introduce a 24 bit type or define char or short or int as 24 bits. It does not make sense to support the latest C++, but then use an exotic byte size.     -----Ursprüngliche Nachricht----- Von:Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 16.07.2025 13:09 Betreff:Re: [std-proposals] CHAR_BIT == 8 p3635r0 An:std-proposals_at_[hidden]; CC:Jan Schultke <janschultke_at_[hidden]>; >  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 don't see how a separate octet type would help. It couldn't actually be narrower than a byte anyway; it could just have some padding bits. The strategy on non-8-bit-platforms is to just leave some bits unused for operations that use char/unsigned char, and that seems fine for networking too. You don't actually need an octet type. I still think we should drop support for non-8-bit bytes completely. Part of the reason is that we now have <simd>, <linalg>, and the list of standard numerics features only keeps growing. All of these are freestanding, and it would require heroic effort for any niche architecture to provide high QoI for such features. Are we really expecting vendors to create and maintain a decent implementation of <simd> for their DSPs from scratch? C++ has become too big for non-8-bit, realistically. Maybe it will take some more time, but that realization will eventually sink in. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals