sizeof ptrs,lint,etc

[Ron Natalie <ron>]

> 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(??? *).
Yes, and on machines where only the second case is true, the example that
Chris gives will fail.  This happens on machines that have perfectly
reasonable archictures, but larger word sizes.  On the Denelcor HEP
for instance, the word size is 64 bits and that is the size of int and
long.  64 bits is massive overkill for a pointer, 32bits is used and
guess what?  Shorts are only 16 bits, there is no integer that corresponds
the the size of a pointer.  And like many other machines long pointers
short pointers and char pointers all have different representations
(albeit they do have the same size).

> We all want
> C & UNIX to run everywhere, but let's not bend over backwards to
> accommodate weird architectures.

If by using LINT and careful program coding you can achieve portability,
why not?  The whole point of C is to give the USER a chance at portability,
not to prohibit nor require it (this was one of the policy statements of
the ANSI C people).  The whole point of making them portable is to avoid
areas of problem, like making blind assumptions about type sizes, rather
than arguing that certain machines should not be allowed to exist.

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

So, it's up to you.  Go ahead and write non-portable code if you don't
want to have to worry about making it run on "wierd" machines.   I don't
think we should tell the C implementers on these machines to do purposefully
inefficient implementations of C.  I want a reasonable compiler on these
machines, because I don't want them to give up on C as the systems programming
language.

>    The nil pointer in C *IS* a bit pattern of some size all zeros. This
> is not lisp. 

Yes this is not lisp. Sorry, but once again the nil pointer *IS NOT*
guaranteed to be of some size and all zeros.  It's not guaranteed to
have a size at all.  There is no nil pointer.  All you are guaranteed is
that you can assign zero to a pointer and compare a poineter to zero
reliably, and that what ever it maps zero to when it stores it will
never look like a valid pointer. We could just as easily map "0" to -1
in a PDP-11 int pointer, since they are guaranteed to not be valid when
odd.  Some systems even have out of the word bits indicating pointer
validity, that could be used.


IN CONCLUSION, one of the really nice things about C (which you are
also noticing), is that it allows you to stand on your head and be
portable or blatently ignore the consequeces when you "know" what is
going to happen.  This flexability can be seen in all great works
such as the Constitution of the United States or Army Regulation
380-380.

-Ron