Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!vax135!cornell!uw-beaver!tektronix!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!ron From: ron@brl-tgr.ARPA (Ron Natalie) Newsgroups: net.lang.c Subject: Re: sizeof ptrs,lint,etc Message-ID: <8065@brl-tgr.ARPA> Date: Tue, 5-Feb-85 20:14:32 EST Article-I.D.: brl-tgr.8065 Posted: Tue Feb 5 20:14:32 1985 Date-Received: Sun, 10-Feb-85 04:55:55 EST References: <8058@brl-tgr.ARPA> Organization: Ballistic Research Lab Lines: 62 > 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