You can't have everything, or, K&R in '84

[jer%vanderbilt.csnet at CSNET-RELAY.ARPA]

From:      Eric Roskos <jer%vanderbilt.csnet at CSNET-RELAY.ARPA>


It seems to me that you can only pursue a subject so far before you begin
chasing yourself in circles.

The old K&R book made it quite clear that getchar and the (at the time, new)
Edition 7 getc procedures both were of type int.  It also pointed out that,
if you treated it as a char, your programs were non-portable.

Now, the sort of discussion here in the past 2 weeks gives a lot of fuel
to those who are determined to make programming automated by moving every-
thing they can from the semantic to the syntactic level.

If you are going to have a language that is not strongly typed, and which
generates relatively clean code on all the enormous number of machines,
from 6502s up to Crays, you are going to have to accept that there are
some machines that won't support all your data types.  In particular,
some of them are very unlikely to support 8-bit signed numbers.

Now, K&R told us a long time ago, back when Unix and C were clean and
simple, that if you wanted a powerful tool, you had to use it with some
wisdom. (quick, go get the etymolygists and let's figure out what
"wisdom" and "wizard" have in common.)  One of the wise things you must
do is realize that, if you insist on digging out the deep corners of
C and exploiting things like the fact that some machines let you use
a char (which, someone already pointed out, K&R only guarantee to work
for valid characters in the native machine's character set) as a signed
quantity, you won't get portable programs.  How can you?  A char was
meant to be a character.  A short was meant to be the shortest
quantity for use in portable arithmetic.

This sort of confusion was exactly what led us to have FORTRAN-77;
there were things in FORTRAN-66 which the very clean, understandable
standard said "don't do," and people insisted on doing them.  Now we
have a language with type conversion rules so complicated you have
to keep the table handy just to be sure something will work.

It is also what led us to have ADA.

It's just not reasonable to go digging through the manuals, trying to
show what "AT&T" says at the moment is the "official" way of doing
something that the original language designer didn't intend to be done
in the first place.  They're just people too.

It seems to me that the only way to properly deal with the problem is
this:

#define byte char
byte c;

Now, if you port your program and for some strange reason it won't run,
you can try saying

#define byte short

or

#define byte int

and see if that works.  And maybe someday there'll be a type "byte"
that's always signed (and, I hope this won't inspire too long a discussion
over whether or not it's good to then say 

	unsigned byte x;

since we'll be right back where we started from) and you can leave off
the #defines altogether.

Till then, if you do something the manual says don't do, I don't much
think you can complain.