Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!um-math!sharkey!cfctech!teemc!hpftc!zardoz!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!usc!rutgers!jarvis.csri.toronto.edu!dgp.toronto.edu!flaps From: flaps@dgp.toronto.edu (Alan J Rosenthal) Newsgroups: comp.lang.c Subject: Re: Carrying around excess baggage. Message-ID: <1989Aug30.172710.10571@jarvis.csri.toronto.edu> Date: 30 Aug 89 21:27:10 GMT References: <1418@atanasoff.cs.iastate.edu> Lines: 70 hascall@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