Uses of "short" ?

[preece at ccvaxa.UUCP]

> /* Written  1:46 am  Oct  5, 1985 by guy at sun.uucp in ccvaxa:net.lang.c
> */ Given that the maximum absolute value which an "int" can hold is
> fairly small, it's not particularly safe to ignore considerations of
> range (it's not safe to ignore considerations in precision - in "real"s
> -either, but integers are always precise).
----------
Well, when I say "ignoring considerations in precision" I'm speaking
in ball-park terms.  I know when I have to worry about a value possibly
not fitting in 32 bits.  Most of the quantities most of us deal with
most of the time are small integers.
----------
> I don't want them to have a pretty good idea when it's going to violate
> that default assumption on a particular machine.  I want them to have a
> pretty good idea when it's going to violate that default assumption on
> a 16-bit-"int" machine;
----------
Well, I can see how that would make life easier for you, but it's not
really my problem.  The project I work on would have saved a lot of
time if the code we're porting hadn't been written for a system using
memory-mapped files, but I don't curse the authors for writing for the
environment they had.
----------
> K&R states quite clearly that "int" takes up 16 bits on PDP-11s, so
> there exists at least one (very popular) machine on which the "default
> assumption" about "int" would be violated.
----------
It also states quite clearly that on PDP-10s an int is 36 bits.  I
don't see why I should give more weight to one than the other.  The
definition of short, int, and long is EXPLICITLY machine dependent
in K&R.  The key phrase, in my opinion, is "'Plain' integers have the
natural size suggested by the host machine architecture; the others
are provided to meet special needs."  That is pretty explicit.
----------
> (Consider all the postings that say "our news system truncates items
> with more than 64KB, so could you please repost XXX" for an example of
> why it is a bad practice.)
----------
What has that to do with anything?  Somebody failed to anticipate
future needs and used a short when she should have used a long.
There are people who rely on two-digit year codes, too.
----------
> People *porting* software shouldn't have to be aware of those places.
> People *writing* software - even if they "know" that it'll never be
> ported - should be aware of them.
----------
Portability is one of many factors to be considered in setting local
coding standards.  I have spent a lot of time recently understanding
code written for a very different environment and converting it to C.
It had lots of size and byte-ordering problems.  That's the breaks.
It's not the authors' fault that I had different requirements than they.

Now, if I worked for a company in the business of writing software to
be marketed across a wide variety of machines and architectures,
we would have local conventions designed to make those transitions
easy.  But it is not our business to produce code that runs on PDP-11s,
let alone (as you requested in a previous posting) code that runs
efficiently on PDP-11s.
----------
> Hogwash.  If you write code that assumes an "int" can hold things
> outside that range, you should put something like
> 
> 	#ifdef pdp11
> 		FORGET IT, NO WAY, GIVE UP AND GO HOME
> 	#endif
>
> to emphasise that this code will not run on a PDP-11.
----------
I don't consider the PDP-11 to be a sacred special case.  We have code
that would break on a PDP-10, too, because it would NOT get arithmetic
exceptions where we expect them.  So?

Here's a concrete example.  I don't blame Gosling for alignment
problems we had in making Emacs run on our machines.  It wasn't
a consideration he should have had to worry about.  I DO fault
Unipress for having the same problem in the latest versions,
because that IS something they should have to worry about.

I have no objection to the principle that we should try, other things
being equal, to write portable code.  But the FIRST consideration of
good professional practice is to write code that is clear,
maintainable, and efficient in the environment for which we are paid
to produce it.  It is not bad practice to put that environment first.

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece