lint, pointers, 0 (what else?)

Thomas M. Breuel breuel at harvard.ARPA
Wed Feb 6 16:13:03 AEST 1985


[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.



More information about the Comp.lang.c mailing list