Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxb!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.lang.c Subject: Re: lint, pointers, 0 (what else?) Message-ID: <424@rlgvax.UUCP> Date: Wed, 6-Feb-85 13:07:35 EST Article-I.D.: rlgvax.424 Posted: Wed Feb 6 13:07:35 1985 Date-Received: Fri, 8-Feb-85 02:15:32 EST References: <366@harvard.ARPA> Distribution: net Organization: CCI Office Systems Group, Reston, VA Lines: 119 > 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. Sorry, Doug is right; explicitly flagging discarded return values is often useful - it warns the reader that the code may not be checking for error returns (if I had a nickel for each time I've been burned by a program not checking for error returns I could single-handedly eliminate the deficit). > [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'?). So? Before "termcap" existed, people wrote programs that controlled display terminals by directly using control strings which were compiled into the program. These programs still exist, work, and are used, but they are useless at a site which doesn't have the terminal they were written for. *Modern* programs should be written to use things like "termcap", and old programs may have to be rewritten. That's life. We had to bash a number of System III programs to make them more type-correct to run on our 16-bit-"int"/32-bit-pointer machine (and to keep them from trying to dereference null pointers). > Apart from habit, there are also the problems you will run into when > implementing the generic null pointer "Implementing the generic null pointer" is like "trisecting an angle with compass and straightedge". There is no generic null pointer in C (as has been pointed out in this newsgroup far too many times already). As such, the problems of "implementing the generic null pointer" are irrelevant. > > Finally, there is no good reason for not having > sizeof(int)==sizeof(char *). 'int' is not guaranteed to be the fastest > integer type around To quote from K&R (p. 183): ``Plain'' integers have the natural size suggested by the host machine architecture... The Motorola 68000 speaks with forked tongue here. 16 bits is suggested by the 16-bit data paths used for non-address arithmetic (2 extra clocks for a 32-bit "add", f'rinstance), by the lack of 32-bit multiply or divide instructions, and by the 16-bit external bus. 32 bits is suggested by the large address space. There is, thus, a good reason for having sizeof(int) == 2 and sizeof(char *) == 4 - speed of execution. There is also a good reason for having them both == 4 - it would be nice to have an "int" hold the size of an object larger than 65535 bytes. There's a tradeoff here; depending on your application, either one could be the correct choice. > And if you are worried about getting an efficient integer type portably, > why don't you just use 'typedef short EfficientInt;' :-? That's the best solution, but it doesn't help completely; arguments to procedures have to be widened to "int". > [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 Oh? Have you asked K or R about this? Do you think that the following code: double foo(x) double x; { double sqrt(); return(sqrt(x)); } main() { printf("%f == 2\n", sqrt(4)); } should work? It doesn't. You have to cast the "4" to "(double)4", because the current C language has no way of telling the compiler that arguments passed to "foo" should be cast to "double". The same holds true for pointers. The ANSI C language standard permits you to declare the types of the arguments of a function, which makes 99% of these problems go away. > While we are on the subject, what about the same treatment for '-1', > the (de facto) standard error return value? What? What treatment? Return values don't have this problem because you can declare the return value of a function. (BTW, it is NOT the standard error return value; "fopen", for instance, returns a null FILE pointer if it fails.) > 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. I am also speaking with experience, I am working with such a compiler, it has done us quite a bit of good (it permits us to write our system and applications code in C, and we *do* make money selling that code) - a 32-bit "int" compiler might do better, but further the deponent sayeth not - and the main problems we have are not problems with the compiler, but problems with people who don't take sufficient care when writing code for it. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy