SIZEOF

[mwm at ucbtopaz.CC.Berkeley.ARPA]

In article <347 at ecr.UUCP> peterc at 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.

	<mike