Carrying around excess baggage.
Gordon Burditt
gordon at sneaky.UUCP
Fri Sep 1 02:08:03 AEST 1989
> 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
More information about the Comp.lang.c
mailing list