strangest systems I've sent email from

It was thus said that the Great Liam Proven once stated: By the late 80s, C was available on many different systems and was not yet standardized. The standards committee was convened in an attempt to make sense of all the various C implementations and bring some form of sanity to the market. All those "undefined" and "implementation" bits of C? Yeah, competing implementations. For instance, why is signed integer arithmetic so underspecified? So that it could run on everything from a signed-magnitude machine [1] to a pi-complement machine (with e-states per bit [2]). Also, to give C implementors a way to optimize code [3][6]. And because of the bizarre systems C can potentially run on, pointer arithmetic is ... odd as well [4]. It also doesn't help that bounds checking arrays is a manual process, but then again, it would be a manual process on most CPUs [5] anyway ... -spc (Wish the C standard committee had the balls to say "2's complement all the way, and a physical bit pattern of all 0s is a NULL pointer" ... ) [1] I think there was only one signed-magnitude CPU commercially available, ever! From the early 60s! Seriously doubt C was ever ported to that machine, but hey! It could be! [2] 2.71828 ... [3] Often to disasterous results. An agressive C optimizer can optimize the following right out: if (x + 1 < x ) { ... } Because "x+1" can *never* be less than "x" (signed overflow? What's that?) [4] Say, a C compiler an 8088. How big is a pointer? How big of an object can you point to? How much code is involved with "p++"? [5] Except for, say, the Intel 432. Automatic bounds checking on that one. [6] Trapping on signed overflow is still contentious today. While some systems can trap immediate on overflow (VAX, MIPS), the popular CPUs today can't. It's not to say they can't test for it, but that's the problem---they have to test after each possible operation. And not all instructions that manipulate values affects the overflow bit (it's not uncommon on the x86, for instance, to use an LEA instruction (which does not affect flags) to multiple a value by small constants (like 17 say) which is faster than a full multiple and probably uses fewer registers and prevents clogging the piplelines).