Carrying around excess baggage.

[Alan J Rosenthal]

hascall at atanasoff.cs.iastate.edu (John Hascall) writes:
>    Some items I would like to see investigated by the "committee on
>    un-American programming activities":

Ok, I'm un-American, so I'll have a go.


I'll split your topics up into a few categories.  The first category is
"Doesn't Matter As Long As You Write Your Programs Correctly".

># of bytes in data types
Would you prefer writing "malloc(4)" to "malloc(sizeof(int))"?
Other than that, why does it matter?

>endian-ness
This is usually hard to observe except in unusual circumstances (network stuff)
or bizarre unportable programs.  And in most of the situations in which it
comes up, the data would have been better written in text form rather than
binary, for human readability.  It's true that there are situations in which
endian-ness is important, but for that see the third category.

>internal value of NULL pointer
This is impossible to observe in correctly written programs.


The next category is called "It Might Be Looking Towards The Future As Well As
Looking To The Past".  To constrain the following would make C obsolete at
some point in the future as things get bigger:

># of bits in a byte
># of bytes in data types
>character encoding
Character encoding will have to change as character sets encompass more
languages and more symbol sets (integral signs etc).
[ I repeated the "# of bytes in data types" item. ]


This category is called "People Expect C To Be Efficient, And They Expect This
Efficiency To Result From C Being Close To The Machine, And Machines Are
Different In These Regards".

>interpretation of shift operations
>integer data format (signing schemes, etc)
>endian-ness
[ I repeated the "endian-ness" item. ]


The final category (miscellaneous):

>floating point data format
Well, ansi C doesn't constrain this, but neither does it constrain keyboard
layout.  However, keyboard layout is certainly important to me, as is floating
point format to some.  You can always insist on ansi C with IEEE floating
point, and I'll insist on a C compiler on a machine with a reasonable keyboard.

>a constant pointer size
I don't know what this means, but if it means that all pointers should have the
same representation, it's in the first category.

--

There are many problems with ansi C, but I don't think any of the above points
represent problems with ansi C.  They represent ways in which ansi C has
recognized the diversity of C environments over space and time.  The diversity
of C environments represented by the above points is good.  There are other
aspects of the diversity of C environments that are not good.  These include
monocase or six character external identifiers, bizarre file systems or file
types, and the common versus ref/def disparity.

ajr