Ian Ollmann (iano@apple.com) on 7/6/10 wrote:
---------------------------
[snip...]
> I used to have that opinion, too. However, lately
> I've been working on a open standards based C language
> derivative and it's becoming increasingly clear just how creaky
> C is as we work through all the different ways that it has to be
> fixed to get different platforms to return the same answer...
[snip...]
> 2) No SIMD vector support / failure to standardize types early
> on -- how big is an int anyway? A double? What is the bit
> pattern for these things? (I group these together because many
> algorithms for vectors require fixed data representations.)

And they *break* things from one version of the standard
to another! C used to guarantee that "long" was the longest
integer type, and lots of us carefully and painfully wrote
code relying on that fact.

Unfortunately too many lazy programmers wrote code with
"long == int32_t" assumptions (particularly at a powerful
PC vendor I won't name), and then influenced the standards committee
to break the codes (silently!) of those who had carefully
followed the standard.

FWIW, one of the worst decisions ever to come out of
Berzerkeley was the BSD C-compiler decision that
long == int == int32_t. At that time it should have been
already clear that 64=-bit stuff would be needed (soon!),
and the code would have been much more portable if their
compiler had said clearly "For us, short == int16_t; int ==
int32_t; long == int64_t". If they had, enough other
vendors might have followed their lead that we would not
have nearly as much mess as we do now.