Why NULL is 0

Guy Harris guy at gorodish.Sun.COM
Tue Apr 5 10:09:57 AEST 1988


> Most of these run on any machine which has the size of int equal sizeof
> pointer, and all pointers are the same in content. This includes the VAX
> and 68000 family. Other machines, such as some Data General models, Cray,
> small Intel processors, SPARC, and some non-UNIX C compilers on any machine
> will not accept this lack of explicit typing.

Umm, I agree with your sentiments whole-heartedly, but I do have to point out
that on SPARC, sizeof (mumble *) == sizeof (frotz *) == sizeof int for all
values of "mumble" and "frotz", and that a "mumble *" contains the address of
the appropriate byte of the "mumble" in question (SPARC being big-endian) for
all values of "mumble".  For better or worse, on SPARC you can get away with
passing 0 or NULL to routines expecting a pointer.  (You'd better not try to
*dereference* that null pointer, though.)

Using tricks such as

	printf(fmt, args)
		char *fmt;
		char *args;
	{
		char *ap;

		...

		ap = &args;

		while ((c = *fmt++) != '\0') {

			switch (c) {

			case 'd':
				int_value = *((int *) ap);
				ap += sizeof int;

		...
	}

won't work on SPARC - you have to use the "varargs" stuff - but that's a
different matter, as is the fact that SPARC requires (2,4,8)-byte alignment of
(2,4,8)-byte atoms (many other chips require some or all of these alignments as
well, including some CISCs such as the WE32100).



More information about the Comp.lang.c mailing list