jer%vanderbilt.csnet@CSNET-RELAY.ARPA (06/18/84)
From: Eric Roskos <jer%vanderbilt.csnet@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.