Thou shalt have no other gods before the ANSI C standard 1383
Thou shalt have no other gods before the ANSI C standard 1384
My wife and I both started to observe this problem about the same time, and that...
In my own crypto-related source code, I often include this:
#if CHARBIT != 8 #error This code requires 8-bit bytes #endif
This means that I do acknowledge that, at some point, someone whom I don't know may try to compile my code on some strange hardware I have never heard about. I do not support hardware with bytes longer than 8 bits, but I make sure that if there is a problem, it will be diagnosed at compile-time. I acknowledge the (possible) existence of such hardware.
The reason for this test is that I-O are not well defined for bytes which are not octets. There is no clear consensus: some systems will store one octet per byte, ignoring the upper bits; others will pack data. But cryptographic algorithms are often defined in terms of octets (see PKCS#1 for instance). So I really wouldn't know what to do with an array of bytes if the bytes are not octets.
Besides, whenever I use a truncation to 8 bits, I make it explicit in my source code. I do not write this:
unsigned char b = z;
unsigned char b = z & 0xFF;
(or a macro-enhanced version) because it makes what really happens clearer for the human who reads the code. The C compiler is smart enough to notice that the "& 0xFF" is redundant, so there is no performance problem at all here.
It so happens that this makes much of my code compatible with machines with larger bytes. But this is only a side effect, and, as explained above, this does not solve the API definition problem for I-O.
Thou shalt have no other gods before the ANSI C standard 1386
Yes, well ... allowing for other ways to make the kids think twice before doing something like that, I can find several (thin) volumes that are all of readable, somewhat effective, and not...
Alt Folklore Computers Newsgroups