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.

Date: Thu, 24 Oct 2019 17:30:00 +0000
From: Lyberta <lyberta_at_[hidden]>
To: Std-Proposals <std-proposals_at_[hidden]>
Subject: [std-proposals] Restrict possible values of CHAR_BIT
Message-ID: <8e78d84f-6f29-c028-009c-f0e5481dbf0c_at_[hidden]>
Content-Type: text/plain; charset="utf-8"

I propose to restrict possible values of CHAR_BIT to be 8 * (2 ^ n) where n is a non-negative integer.

This gives values of 8, 16, 32, 64, 128 and so on.

I have surveyed the most likely hardware architectures that would not fit with this restriction - computers with 24 bit bytes i.e. where CHAR_BIT == 24.

The most extensive information I could find is on Wikipedia:

https://en.wikipedia.org/wiki/24-bit
https://en.wikipedia.org/wiki/Category:24-bit_computers

It seems like the only candidate that is still relevant is Motorola
56000 series:

https://en.wikipedia.org/wiki/Motorola_56000

However, the specification says that it uses 8 bit bytes:

http://cache.freescale.com/files/dsp/doc/inactive/DSP56000UM.pdf

Therefore, I couldn't find implementations where CHAR_BIT == 24 which means other more exotic cases probably never existed.


________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.