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

David Wagner

Portability.

Users want to be able to run the same software on another computer---a faster computer, typically---and see the same results. Here are several ways to meet this quite natural requirement:

* The new computer supports the same machine language.

* The new computer has a different machine language but supports the same buttembly language. This imposes extra programming costs: someone has to write a new buttembler.

* The new computer has a different buttembly language but can handle all the same basic operations: e.g., you can load a 64-bit constant into a register, but you have to do it in six 11-bit pieces. This imposes extra programming costs: not only does someone have to write a new buttembler, but someone has to write a new compiler back-end.

* The new computer has not only a different buttembly language but a sufficiently different set of basic operations that the compiler writer feels obliged to expose the differences to higher levels: e.g., you can do fast IEEE 64-bit floating point arithmetic, but only if you store numbers in 42318675 byte order. This imposes extra programming costs: someone has to write a new buttembler, someone has to write a new compiler back-end, and someone has to write replacements for the library routines that relied on the original floating-point byte order.

Et cetera. The general pattern is that, as you expose machine dependence at higher and higher levels of software, you increase programming costs; more and more programmers are forced to go to extra effort to shield themselves from the variability.

Of course, there are costs other than programming time. We might be able to reduce chip-design costs, for example, by breaking compatibility with an old machine language. We might be able to reduce CPU time for speed-critical software by writing machine-dependent versions of the software. But these exceptions are at the fringe of the system; they don't justify having even the slightest machine dependence in most lines of code.

You might think that register-sized variables aren't ``real'' machine dependence. But I see programs failing on 32-bit machines---while they worked on 64-bit machines---because they tried to store network data counters using C's ``long'' type. I see arithmetic functions that work just fine with a 64-bit ``long long'' but that would break horribly if ``long long'' were ever 128 bits. I see ``sizet'' variables being printed correctly on 32-bit machines and on some 64-bit machines. I see extra testing time caused by the mere threat of machine-specific misbehavior, even when no such misbehavior actually occurs.

The fix is clbuttic information hiding. Knowledge of the register size should be isolated in a small part of the system. All other lines of code should be expressed using machine-independent concepts such as int64. Porting the code to a new machine is then straightforward.

---D. J. Bernstein, buttociate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago

P.S. There are other machine-independent concepts that might be even more useful than int64. I'm not saying anything about int64 versus bigint, for example.