On 10/24/19 4:52 PM, Arthur O'Dwyer via Std-Proposals wrote:

On Thu, Oct 24, 2019 at 4:10 PM Tjernstrom, Staffan via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Looking at interactions with (and by extension, programming on) FPGAs, where everything is bit-based, it's common to find things like 14-bit values. We have 14-bit types in our internal type system.

Yes, but "a 14-bit type exists" is not the same thing as "CHAR_BIT==14". I would be as surprised as Lyberta (and perhaps more so) if any C++ compiler in the world supported "CHAR_BIT==14".

However, I agree with Tom that this proposal is not motivated. Personally I think it'd be just as silly to have CHAR_BIT==16 or CHAR_BIT==32 as to have CHAR_BIT==9 or CHAR_BIT==24. If we're trying to get C++ to fall in line with what "everybody knows," then the way to do that is to mandate CHAR_BIT==8, not to keep the current situation of "CHAR_BIT==I don't know, ask your vendor" but also put odd restrictions on the vendor's choice.

Lyberta, did your survey turn up any C++ implementations where CHAR_BIT != 8? If so, what version of C++ were they — C++03, 11, 14, 17?

Coverity supports a number of compilers where byte size is not 8. I'm not very familiar with these compilers and I don't know which ones (if any) are being maintained. Ones I know of are for targeting the following DSPs. The Analog Devices ones have a 32-bit char, the rest are 16-bit.
- Analog Devices:
   - 21XX
   - TigerSHARC
- CEVA
   - TeakLite 4
- Texas Instruments:
   - C2000
   - C54XX
   - C5500

Additionally, there are apparently people working on LLVM targeting an architecture with a 257 bit byte (that is not a typo).
- http://lists.llvm.org/pipermail/llvm-dev/2019-October/136115.html

Please don't underestimate the potential for C++ to be used for unusual architectures. It is hard to predict what might become mainstream one day.

As an example provided to me by another committee member recently, consider some possibilities of a 48-bit processor. 32-bits is often less than is needed for memory use or floating point precision. But 64-bits is often more than is needed. A 48-bit processor could hit a sweet spot. That could in turn lead to a desire for a UTF-12 encoding and a 12-bit char size that would more efficiently encode text (in some cases) than UTF-8 does today. I'm not stating this would be a good idea, but it is an example that can be defended in principle.

Tom.

my $.02,

–Arthur