Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 v7 ucbtopaz-1.8; site ucbtopaz.CC.Berkeley.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxb!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!talcott!panda!genrad!decvax!ucbvax!ucbtopaz!mwm From: mwm@ucbtopaz.CC.Berkeley.ARPA Newsgroups: net.lang.c Subject: Re: SIZEOF Message-ID: <687@ucbtopaz.CC.Berkeley.ARPA> Date: Mon, 28-Jan-85 16:19:32 EST Article-I.D.: ucbtopaz.687 Posted: Mon Jan 28 16:19:32 1985 Date-Received: Wed, 6-Feb-85 04:40:00 EST References: <347@ecr.UUCP> Reply-To: mwm@ucbtopaz.UUCP (Praiser of Bob) Organization: Univ. of Calif., Berkeley CA USA Lines: 49 Summary: In article <347@ecr.UUCP> peterc@ecr.UUCP (Peter Curran) writes: >Of course, C SHOULD be defined to allow sizeof(int) != sizeof(int *). >However, due to one point in the Reference Manual, and K&R (and, I assume, >the standard, although I haven't checked), they are actually required to >be equal. The problem is that "0" is defined to be the Null pointer >constant. Sorry, but that's not quite right. Quoting K&R, page 192, first paragraph, last sentence: However, it is guaranteed that assignment of the constant 0 to a pointer will produce a null pointer distinguishable from a pointer to any object. In other words, "0" is not the null pointer constant, but coerces to it on assignment to a pointer. > When "0" is passed as a parameter to a function, the compiler >cannot tell whether an int or an int * is intended. Yup. That why you need to cast NULL parameters to the right type. Not doing the cast is a bug that will work on some machines, but not on all machines. > The effect of this is >that sizeof(int) must equal sizeof(int *), and even more, the value of the >Null address constant must be bit-for-bit identical to the value of ((int) 0). No. The effect is that the null address constant of type (type) must be bit-for-bit identical to ((type *) 0). ((int) 0) and ((type *) 0) don't even have to be the same size. >Of course, many compilers do not conform to this requirement. The problem >can be avoided by, for example, always using (say) NULL as the Null >address constant, where NULL is #defined as something like ((char *) 0). I've done that, but it's a kludge. The code will still be buggy, and the bugs will manifest themselves on any machine where (sizeof (char *)) != (sizeof (int *)) != (sizeof (struct gort *)). This is one of the reasons adding the parameters to the declaration of an external (or forward-referenced) function. >The real solution, of course, would be to introduce a new keyword, say "null", >which represents the Null address constant, with an implementation- >defined value. However, I doubt that that will ever come about. Sounds like a good idea to me. Trouble is, you still have the problem of figureing out which "null" to pass to an external procedure.