sizeof ptrs,lint,etc

[cottrell at nbs-vms.ARPA]

/*
As promised, here are more irrational viewpoints:
> > i DO believe that sizeof(foo *) should be sizeof(bar *). otherwise it's
> > just too confusing. more irrational viewpoints later.
> 
> It's too confusing only if you're easily confused.  Cast your d*mn pointers
> properly (like "lint" tells you to do) and lots of problems go away.
> If you absolutely *need* a pointer that can point to any one of ten
> things, and a union of ten pointer types won't do, use "char *" (or "void *"
> if/when it appears in the ANSI standard).
> 
> 	Guy Harris
> 	{seismo,ihnp4,allegra}!rlgvax!guy

Oh my brain hurts! (Is Guy out to get me or am I just paranoid? :-)
I hate lint. All it ever does is complain about code that I know works.
I don't like casting funxions to (void). I don't like casting arguments
to funxions. I don't like /*NOTREACHED*/. I do `if (exp) return exp;'
to avoid the braces when I really mean `if (exp) { exp; return;}'
I don't declare args as ptrs if I merely pass them on to another funxion.
Even the UNIX REVIEW they gave away at Uniforum says that void just makes
programs harder to read. What I do with lint is sweep it under the rug.

Chris Torek writes:
> NO! NO! and NO!
> 
> [please turn your volume control way up]  PASSING AN UNCASTED ZERO
> TO A ROUTINE THAT EXPECTS A POINTER IS NOT PORTABLE, AND IS JUST PLAIN
> WRONG.  GET THAT STRAIGHT *NOW*!
> 
> [you can turn your volume control back down]
> 
> The following code is NOT portable and probably fails on half the
> existing implementations of C:
> 
> 	#define NULL 0		/* this from <stdio.h> */
> 
> 	f() {
> 		g(NULL);
> 	}
> 
> 	g(p) int *p; {
> 		if (p == NULL)
> 			do_A();
> 		else
> 			do_B();
> 	}
> 
> The value ``f'' passes to ``g'' is the integer zero.  What that
> represents inside g is completely undefined.  It is not the nil
> pointer, unless your compiler just happens to work that way (not
> uncommon but not universal).  It may not even be the same size (in
> bits or bytes or decidigits or whatever your hardware uses).
> 
> One tiny little simple change fixes it:
> 
> 	f() {
> 		g((int *)NULL);
> 	}
> 
> It is now portable, and all that good stuff.  You can write the
> first and hope real hard, or you can write the second and know.
> 
> The point is that the zero value and the nil pointer are two completely
> different things, and the compiler happens to be obliged to convert the
> former to the latter in expressions where this is forced (e.g., casts
> or comparison with another pointer).  It is NOT forced in function
> calls (though under the ANSI standard it would be in some cases).
> (I claim that it IS forced in expressions such as if (p) where p is a
> pointer; this is "if (p != 0)" where type-matching p and 0 forces the
> conversion.)
> 
> (Now I WILL agree that if you have the option of making the nil pointer
> and the zero bit pattern the same, then you will have less trouble with
> existing programs if you do....)
> -- 
> (This line accidently left nonblank.)
> 
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
> UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
> CSNet:	chris at umcp-cs		ARPA:	chris at maryland

While I hate to disagree with such a Wizard as C.T. (I can just see my
brother yelling across uom "no he doesn't, Chris, he LIKES to argue...)
LET'S GET BACK TO BASICS!!! What have they done to the poor C language?
It used to be quite clean. It was originally developed on a pdp-11, ported
to an Interdata 8/32, Honeywell 6000, & IBM 370. On each of these machines,
	either sizeof(int) = sizeof(int *) = sizeof(??? *)
	or     sizeof(long)= sizeof(long*) = sizeof(??? *).
Of these, the h6000 is not byte addressable & so the bizarre pointer
format of K&R page 211 is used. Note that a pointer is always 36 bits
even tho half may be unused. So far, so good. Now somewhere along the line
someone broke the rule & decided that maybe pointers to different objects
should be different lengths. The pros? Possible storage savings. The cons?
Now I have to cast pointers. The universe is out of kilter! What about
pointers to pointers? Is sizeof(int **) = sizeof(char **)? We all want
C & UNIX to run everywhere, but let's not bend over backwards to
accommodate weird architectures. If space is sometimes wasted on a
weird machine, it is for conceptual simplicity. When & if a prog is
ported to a bizarre machine it will probably have to be tinkered with
anyway. ALL THINGS IN MODERATION, INCLUDING PORTABILITY.
   The nil pointer in C *IS* a bit pattern of some size all zeros. This
is not lisp. If you want to generate a cell called `nil' & explicitly
compare to `(??? *) &nil' be my guest. The syntax `if (p)' or `if (!p)'
suits me just fine.
*/