Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!pp!milano!cadillac!pebbles!ned
From: ned@pebbles.cad.mcc.com (CME Ned Nowotny)
Newsgroups: comp.lang.c
Subject: Re: Referencing NULL pointers
Message-ID: <1796@cadillac.CAD.MCC.COM>
Date: 19 Jul 89 16:34:17 GMT
References: <32UP02Eg3d=801@amdahl.uts.amdahl.com> <1382@bruce.OZ> <1759@cadillac.CAD.MCC.COM> <10556@smoke.BRL.MIL>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: ned%cad@MCC.COM (CME Ned Nowotny)
Organization: MCC CAD Program, Austin, TX
Lines: 69

In article <10556@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1759@cadillac.CAD.MCC.COM> ned%cad@MCC.COM (CME Ned Nowotny) writes:
>>However, there are environments where addresses can be represented
>>by numeric constants and there really is something important at address 0.
>
>There better not be.  C guarantees that valid object addresses compare
>unequal to null pointers, and since a null pointer constant is written
>as "0" in C source code, you cannot obtain a valid object address by
>casting 0 to the object pointer type.
>
>If this is really a problem for some implementation, then it can arrange
>for the "equivalent integer" mapped form of pointers to be essentially
>the conventional machine address plus one, or some similar mapping that
>keeps 0 from appearing to be a possible valid object address in a C
>program.

While Chris Torek and you have made good arguments against attempting
to cast a 0 to a valid pointer, I believe you are losing sight of
the distinction between a null pointer represented by the numeric
constant 0 and the address 0 in a given environment.

There are byte-addressable systems where important data may reside at
address 0.  On these systems, it is desirable for system specific C
code to be able to bind pointers to specific addresses which have
a one-to-one mapping from integer value to address location.  (Yes,
it would be better to use symbolic names and bind them to specific
addresses in the link editor.  Unfortunately, this is not an option
in most cases.)

Now C adopted a convention that maps well into it's set of logical
operations whereby a 0 represents a null pointer.  In fact, this was
stated in much stronger terms than a mere convention even in K&R I.
However, the language is distinct from the environment.  Other
languages do not care whether 0 is a valid address or not.  If you
can get a handle on it (In *gasp* BASIC, "peek" will do.), you can
read the contents.  The C language description is distinct from
whether useful data resides at address 0.  The question is how do
you get at it if it is there?

The two clean (?) solutions are to either write an assembly language
routine(s) to access the data and link it with your C program or to
have a link editor capable of the trick described above.  The first
is generally more trouble than it is worth and the second may not be an option.
Therefore, Chris's trick using an integer variable set to 0 and cast
to the appropriate pointer type is a desirable approach when writing
non-portable, system-specific code on a byte-addressable system which
implements a one-to-one mapping between addresses and integers.  These
constraints describe a wide range of environments and it almost certainly
is not in the interest of compiler vendors to complicate things by
using an offset mapping as you describe.  Besides, if integers (i.e. unsigned
longs) are the same size as pointers, you will have problems accessing the
highest address location and frequently this is as important as the lowest
address location, 0.

It is absolutely true that C dictates that a null pointer can never point to
a valid object and that this condition must hold when writing portable code.
It is almost universally true that programs that do dereference null pointers
are broken even if they appear to "work" in some environments.  If this were
to be worth discussion, it would probably have best been covered in comp.lang.c
or comp.std.c.  If anything justifies covering it here, it is the question of
whether there are cases in which valid data resides at location zero in some
systems, including implementations of UNIX, and the question of how to access
it.  (Then again, perhaps not.)


Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX  78720  Ph: (512) 338-3715
ARPA: ned@mcc.com                   UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.