What platforms have something other than 8-bit char?

Question

Every now and then, someone on SO points out that char (aka \'byte\') isn\'t necessarily 8 bits.

It seems that 8-bit char is almost universal. I would h

Answer 1

Machines with 36-bit architectures have 9-bit bytes. According to Wikipedia, machines with 36-bit architectures include:

• Digital Equipment Corporation PDP-6/10
• IBM 701/704/709/7090/7094
• UNIVAC 1103/1103A/1105/1100/2200,

Answer 2

The DEC PDP-8 family had a 12 bit word although you usually used 8 bit ASCII for output (on a Teletype mostly). However, there was also a 6-BIT character code that allowed you to encode 2 chars in a single 12-bit word.

Answer 3

what sort of consideration is it worth giving to platforms with non-8-bit char?

magic numbers occur e.g. when shifting;

most of these can be handled quite simply by using CHAR_BIT and e.g. UCHAR_MAX instead of 8 and 255 (or similar).

hopefully your implementation defines those :)

those are the "common" issues.....

another indirect issue is say you have:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

this might "only" take (best case) 24 bits on one platform, but might take e.g. 72 bits elsewhere.....

if each uchar held "bit flags" and each uchar only had 2 "significant" bits or flags that you were currently using, and you only organized them into 3 uchars for "clarity", then it might be relatively "more wasteful" e.g. on a platform with 24-bit uchars.....

nothing bitfields can't solve, but they have other things to watch out for ....

in this case, just a single enum might be a way to get the "smallest" sized integer you actually need....

perhaps not a real example, but stuff like this "bit" me when porting / playing with some code.....

just the fact that if a uchar is thrice as big as what is "normally" expected, 100 such structures might waste a lot of memory on some platforms..... where "normally" it is not a big deal.....

so things can still be "broken" or in this case "waste a lot of memory very quickly" due to an assumption that a uchar is "not very wasteful" on one platform, relative to RAM available, than on another platform.....

the problem might be more prominent e.g. for ints as well, or other types, e.g. you have some structure that needs 15 bits, so you stick it in an int, but on some other platform an int is 48 bits or whatever.....

"normally" you might break it into 2 uchars, but e.g. with a 24-bit uchar you'd only need one.....

so an enum might be a better "generic" solution ....

depends on how you are accessing those bits though :)

so, there might be "design flaws" that rear their head.... even if the code might still work/run fine regardless of the size of a uchar or uint...

there are things like this to watch out for, even though there are no "magic numbers" in your code ...

hope this makes sense :)

Answer 4

There is no such thing as a completely portable code. :-)

Yes, there may be various byte/char sizes. Yes, there may be C/C++ implementations for platforms with highly unusual values of CHAR_BIT and UCHAR_MAX. Yes, sometimes it is possible to write code that does not depend on char size.

However, almost any real code is not standalone. E.g. you may be writing a code that sends binary messages to network (protocol is not important). You may define structures that contain necessary fields. Than you have to serialize it. Just binary copying a structure into an output buffer is not portable: generally you don't know neither the byte order for the platform, nor structure members alignment, so the structure just holds the data, but not describes the way the data should be serialized.

Ok. You may perform byte order transformations and move the structure members (e.g. uint32_t or similar) using memcpy into the buffer. Why memcpy? Because there is a lot of platforms where it is not possible to write 32-bit (16-bit, 64-bit -- no difference) when the target address is not aligned properly.

So, you have already done a lot to achieve portability.

And now the final question. We have a buffer. The data from it is sent to TCP/IP network. Such network assumes 8-bit bytes. The question is: of what type the buffer should be? If your chars are 9-bit? If they are 16-bit? 24? Maybe each char corresponds to one 8-bit byte sent to network, and only 8 bits are used? Or maybe multiple network bytes are packed into 24/16/9-bit chars? That's a question, and it is hard to believe there is a single answer that fits all cases. A lot of things depend on socket implementation for the target platform.

So, what I am speaking about. Usually code may be relatively easily made portable to certain extent. It's very important to do so if you expect using the code on different platforms. However, improving portability beyond that measure is a thing that requires a lot of effort and often gives little, as the real code almost always depends on other code (socket implementation in the example above). I am sure that for about 90% of code ability to work on platforms with bytes other than 8-bit is almost useless, for it uses environment that is bound to 8-bit. Just check the byte size and perform compilation time assertion. You almost surely will have to rewrite a lot for a highly unusual platform.

But if your code is highly "standalone" -- why not? You may write it in a way that allows different byte sizes.

Answer 5

When writing code, and thinking about cross-platform support (e.g. for general-use libraries), what sort of consideration is it worth giving to platforms with non-8-bit char?

It's not so much that it's "worth giving consideration" to something as it is playing by the rules. In C++, for example, the standard says all bytes will have "at least" 8 bits. If your code assumes that bytes have exactly 8 bits, you're violating the standard.

This may seem silly now -- "of course all bytes have 8 bits!", I hear you saying. But lots of very smart people have relied on assumptions that were not guarantees, and then everything broke. History is replete with such examples.

For instance, most early-90s developers assumed that a particular no-op CPU timing delay taking a fixed number of cycles would take a fixed amount of clock time, because most consumer CPUs were roughly equivalent in power. Unfortunately, computers got faster very quickly. This spawned the rise of boxes with "Turbo" buttons -- whose purpose, ironically, was to slow the computer down so that games using the time-delay technique could be played at a reasonable speed.

---

One commenter asked where in the standard it says that char must have at least 8 bits. It's in section 5.2.4.2.1. This section defines CHAR_BIT, the number of bits in the smallest addressable entity, and has a default value of 8. It also says:

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

So any number equal to 8 or higher is suitable for substitution by an implementation into CHAR_BIT.

Answer 6

Many DSP chips have 16- or 32-bit char. TI routinely makes such chips for example.