Path: utzoo!mnetor!uunet!husc6!think!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Why NULL is 0
Message-ID: <48209@sun.uucp>
Date: 5 Apr 88 00:09:57 GMT
References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP> <10229@steinmetz.steinmetz.ge.com>
Sender: news@sun.uucp
Lines: 41

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