Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!ron From: ron@brl-tgr.ARPA (Ron Natalie) Newsgroups: net.lang.c Subject: Re: lint, pointers, 0 (what else?) Message-ID: <8094@brl-tgr.ARPA> Date: Wed, 6-Feb-85 16:26:10 EST Article-I.D.: brl-tgr.8094 Posted: Wed Feb 6 16:26:10 1985 Date-Received: Sun, 10-Feb-85 04:06:36 EST References: <366@harvard.ARPA> Distribution: net Organization: Ballistic Research Lab Lines: 48 > Finally, there is no good reason for not having > sizeof(int)==sizeof(char *). 'int' is not guaranteed to be the fastest > integer type around (speedof(int)<=speedof(short) on practically all > machines...). And if you are worried about getting an efficient integer > type portably, why don't you just use 'typedef short EfficientInt;' :-? > K&R (quoting from my mind) calls 'int' the 'natural' choice for an > integer data type on the target machine. In my opinion, the 'natural > choice' is the size of a pointer (the largest pointer that is). Yes there is! There is no good reason for you to be too lazy to allow it. C is a systems programming language. I balk at having it bastardized into an unusable higher level language. You can not make an assumption about the sizes. The implementation of the compiler types should be the best for the operation of that system. If you care not to write code that is portable to those machines, thats your affair, but I can't justifying adding an artificial restriction on the language just to make you happy. Quoting K&R from the book: "Plain" integers have the natural size suggested by the host machine architecture. This means WORD size on most machines, since that is arithmatically the basic element. Newer machines with larger word sizes may have smaller pointer sizes, older machines with smaller word sizes required larger pointers. STOP RUINING C FOR SYSTEMS PROGRAMMING. > [null pointer] > > I don't care whether the null pointer spells out Mona Lisa in EBCDIC, > as long as I can compare it to '0', assign it as '0', and (sorry, I > like it) pass it as '0' where a pointer should go -- without casting, The new C standard allows you to do this. But what do you want the compiler to do now, be clairvoyant? How is it supposed to tell that 0 is indeed a pointer, rather than the plain integer constant when passed to a function, so that it can change the size (or in your case) map it to MONALISA in EBCDIC. > The way K&R intended (and partially documented it). It isn't clear that they ever intended it to work this way. > While we are on the > subject, what about the same treatment for '-1', the (de facto) standard > error return value? > Why not say that all integers are mappable to pointers, hey lets do away with types at all!