Carrying around excess baggage.

[Doug Gwyn]

In article <1418 at atanasoff.cs.iastate.edu> hascall at atanasoff.cs.iastate.edu (John Hascall) writes:
>    All the (proposed) ANSI C standard seems to have done is made every
>    quirky little implementation "official".

That's definitely not true.  Implementations were allowed freedom where
it was obviously necessary, and where C's use as a systems programming
language required it.  This is not new; C has always had these loosities.
In many ways the proposed standard requires existing practice to be
"tightened up".

>    Other scientific and engineering disciplines have managed to shed
>    their past false steps, why can't we?

They don't close down old, safe bridges simply because a new bridge
design would be better in the light of current knowledge.

>    Some items I would like to see investigated by the "committee on
>    un-American programming activities":
>	  # of bits in a byte
>	  # of bytes in data types

There is no reasonable defense I know of for over-constraining these.
I don't even LIKE bytes, and I sure don't want to be told that my
computer designs have to provide exactly 8-bit chunking.

>	  character encoding
>	  floating point data format

There are standards for this, but they're not universally adopted.
I guess it was hard to convince people that they should discard
billions of dollars' worth of existing equipment and software.

>	  integer data format (signing schemes, etc)
>	  endian-ness
>	  interpretation of shift operations

There are good arguments for allowing freedom for these designs.

>	  internal value of NULL pointer

This one is nobody's business.

>	  a constant pointer size

This one would serve no useful purpose and would be problematic for
word-oriented (i.e. FAST) architectures.

etc.