Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!texsun!letni!sneaky!gordon
From: gordon@sneaky.UUCP (Gordon Burditt)
Newsgroups: comp.lang.c
Subject: Re: Carrying around excess baggage.
Message-ID: <16770@sneaky.UUCP>
Date: 31 Aug 89 16:08:03 GMT
References: <1418@atanasoff.cs.iastate.edu>
Reply-To: gordon@sneaky.UUCP (Gordon Burditt)
Organization: Gordon Burditt
Lines: 74

>    All the (proposed) ANSI C standard seems to have done is made every
>    quirky little implementation "official".  If it didn't follow the

Look at your list more carefully.  It makes most every quirky HARDWARE
implementation usable if you try hard enough.  It addresses nothing about
compilers that don't catch errors, or have strange quirks that make
people think they are actually features, as in:
# define ctrl(x) 'x'
which is better defined as
# define ctrl(notused) 'x'
because they should do exactly the same thing.

>    spirit (or even the word of) K&R, so what we'll just expand the
>    standard a little.
>
>    Other scientific and engineering disciplines have managed to shed
>    their past false steps, why can't we?

It is interesting that the "mistakes" to be shed are HARDWARE "mistakes",
for the most part, not software mistakes, like dereferencing NULL pointers.
>
>    Some items I would like to see investigated by the "committee on
>    un-American programming activities":

Won't do any good.  Contact the "committee on un-American CPU Design".

>	  # of bits in a byte			Hardware.
>	  # of bytes in data types		Constrained by hardware
						with some limited choices 
						available to software.
>	  character encoding			Largely constrained by
						character sets used by 
						terminals and printers,
						and efficiency considerations.

>	  integer data format (signing schemes, etc)	Hardware.

>	  floating point data format		Hardware, except for
						machines with pure software
						emulation of floating point.

>	  endian-ness				Hardware.  Although it's 
						possible to "fight" this,
						it introduces extreme 
						inefficiency.

>	  internal value of NULL pointer	Often very limited by
						hardware memory management
						schemes.

>	  a constant pointer size		If the hardware doesn't 
						cooperate, this can result in
						significant overhead, like
						many pointers occupying twice
						as much space as they should.

>	  interpretation of shift operations	Fighting the hardware here
						can result in significant
						overhead.

>    Now I realize how much trouble it would be to pin all these down this
>    late in the game, but it sure would make writing portable code a lot
>    easier (it would almost come automatically, which would be quite a plus
>    given the dearth of attention paid to portability in CS courses).

Increasing portability by restricting the scope so you don't have to worry
about the quirks of that implementation doesn't increase the number of
machines it will run on.  It just says "we won't bother with porting to
that; it's too wierd, but so we can still call this code portable, we'll
outlaw it".  Writing unportable code and then re-writing the
spec to call it portable doesn't make it any more portable.

					Gordon L. Burditt
					...!texbell!sneaky!gordon