Thou shalt have no other gods before the ANSI C standard 1383

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;

but this:

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.

--Thomas lovein