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