Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!vax135!cornell!uw-beaver!tektronix!decvax!genrad!panda!talcott!harvard!breuel From: breuel@harvard.ARPA (Thomas M. Breuel) Newsgroups: net.lang.c Subject: lint, pointers, 0 (what else?) Message-ID: <366@harvard.ARPA> Date: Wed, 6-Feb-85 01:13:03 EST Article-I.D.: harvard.366 Posted: Wed Feb 6 01:13:03 1985 Date-Received: Sun, 10-Feb-85 03:33:36 EST Distribution: net Organization: Harvard University Lines: 61 [in reply to Doug Gwyn's remarks...] [ignoring return values] Many functions in 'C' return helpful values, which can, however, safely be ignored most of the time. Cluttering your code with '(void)' may look impressive and improve your productivity (in lines/hour), but is not going to help the portability or readability of your program. In particular, putting in the cast to void can become as much of a reflex leaving it out. [lint] Sure, lint is very useful for porting and debugging programs. You run it on your code, look at its complaints, and fix them if you think that they are justified. I find it extremely silly, though, to put in all these little 'comments with side effects' just to make it shut up. They look ugly and are worthless as documentation. If you get so many unjustified complaints from lint that you actually need '/*FOOBAR*/' and friends, then there is probably something wrong with your code... [sizeof(int)!=sizeof(char *)] Sure, K&R did not explicitely demand anything else. Many programmers, due to the lack of a standard document, and due to the universal acceptance of sizeof(int)==sizeof(char *) in the early days of 'C', have written many of programs that rely on it, though. It is moot to argue that these programmers were wrong: their programs still exist, work, and are used (ever cc'ed 'sed'?). Apart from habit, there are also the problems you will run into when implementing the generic null pointer in a 'C' in which sizeof(int)!= sizeof(char *). 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). [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 way K&R intended (and partially documented it). While we are on the subject, what about the same treatment for '-1', the (de facto) standard error return value? Altogether: A 'C' compiler with sizeof(int)!=sizeof(char *) has severe problems in the real world (I speak from experience, I am working with one), and is not going to do you much good. Thomas.