Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: non-zero NULL pointers (oh nooooo!) (was: Re: retiring gets(3))
Message-ID: <8058@bloom-beacon.MIT.EDU>
Date: 19 Nov 88 09:51:34 GMT
References: <1988Nov8.054845.23998@utstat.uucp> <7963@bloom-beacon.MIT.EDU> <4509@aldebaran.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Followup-To: comp.lang.c.null_pointers
Lines: 57

In article <4509@aldebaran.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>I know of at least one system where the system convention is not 0;
>Data General MV systems have instructions which take -1 as the null
>pointer value, and this has persisted through many system call
>conventions as well. However, the C implementation still considers a
>null pointer to be 0 even though this requires quite a bit of "glue"
>around some system calls to interface between the two formats.
>Requiring that the "null pointer constant" be 0, as ANSI C does, just
>makes any other implementation painfully difficult (and is begging for
>problems when porting software as well).

If the null pointer convention is not 0, the conversion can be
done by the compiler at compile time.  No run-time glue is
necessary.

We only discuss this every month or so.  The compiler can tell
that "0" is a "null pointer constant," as long as it is in an
initialization, assignment, comparison, or function return
context.  It can then generate whatever bit pattern is
appropriate.

     Q:	Wait a minute.  Does that mean that if I write
		register char *p = 0;
	the compiler could generate
		move #FFFF, r4
	?

     A:	Precisely.

The fact that the null pointer constant in C is "0" does not,
repeat not, place any restrictions on the bit pattern used by the
generated code.  Using "0," rather than some machine-dependent
value, increases portability: the translation to the machine-
dependent value is made by the compiler, along with all
of the other machine-dependent translations.  (Sadly, the use of
0 as the null pointer constant has increased programmer confusion
more than it has decreased machine dependencies.)

If, in fact, the compiler for the Data General MV systems
referred to above generates code for null pointers having a bit
pattern of 0, requiring run-time code to translate them to -1 at
the system call interface, it may have been to defend against
(unportable, incorrect) code which failed to differentiate null
pointer constants from integer zeroes in the one context where
the compiler can not distinguish them: function calls.
Programmers must use explicit casts to the correct pointer type
when passing null pointers to functions.  (This restriction is
relaxed if an ANSI-style function prototype is in scope, since
function call context is then equivalent to assignment context.)

If you don't understand this, or have questions, for God's sake
don't post a followup article.  All of the questions and all of
the attendant confusion have been discussed on this newsgroup
countless times before.  (Send mail if you must.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu