Creating pointer with all bits 0 (was: Referencing NULL pointers)

[Jeffrey Kegler]

In article <2030 at se-sd.NCR.COM> rns at se-sd.UUCP (Rick Schubert (AEP)) writes:
>In article <1989Aug31.052756.18524 at sq.sq.com> msb at sq.com (Mark Brader) writes:
>[Someone suggested:]
> >> > could you not access memory location 0 by writing:
> >> >	p = 0;  /* integer variable that happens to be set to zero */
> >> >	data = *(int *)p;  /* no constant expression in this line */
>[To which Mark Brader responded:]
> 
> >      int *p;
> >      memset ((void *) p, 0, sizeof p);
> >      data = *p;
>
> >It may as well be repeated for anyone who's coming in late that
> >the point here is to get a pointer p with all bits zero, for use
> >on a machine where null pointers have some other pattern of
> >bits and all-bits-zero is a meaningful pointer. ...

For those who may not know, constant pointers, that is pointers which
are not created by taking an address or created by malloc(), are
required in some types of programming.  UNIX device drivers and
interfaces in any OS to boards which have registers at fixed
addresses, must have constant pointers to addresses whose bit pattern
is dictated by the hardware.  The bit pattern 0x0 of whatever length
might be one of the addresses required.

As far as I can follow the dpANS, any such code requires some trick
whose behavior is implementation-defined or undefined behavior.
That's fine, since any such code is inherently not portable, could
never be strictly conforming, and only makes sense on a given
architecture.  "Undefined behavior" does not mean the implementation
must blow up in your face.  It means the implementation may do
anything that it pleases--blow up in your face or work as you
intended.

Each implementation on an architecture where constant pointers may be
necessary will, in some circumstance where dpANS allows
"implementation defined behavior" or "undefined behavior", allow
access to the appropriate fixed locations.  Which tricks the
implementation will allow and how they work is up to the
implementation.  In Footnote 42 to 3.3.4 dpANS expresses the hope
implementors will use integers cast to pointer as the allowed trick to
accomplish this.  But dpANS seems to allow anything that does not
break a strictly conforming program, so long as the implementation
documents its choice.  Since no strictly conforming program can try
any of these tricks, this is not a major restriction.

Apparently the only difference between allowing implementation defined
behavior and allowing undefined behavior is that documentation of the
former is required, no matter what, while documentation of the latter
is optional.

Question: Is an implementation whose null pointer is the same as the
result of some integer-to-pointer cast conforming?  Apparently not,
since 3.2.2.3 states, "... a null pointer is guaranteed to compare
unequal to a pointer to any object or function."

If I am correct, this could cause problems.  It is not hard to imagine
an implementation where every possible pointer bit pattern is a valid
physical address.  No pattern would remain for the null pointer.  The
implementation would have to carry an extra bit or more with each
pointer, rendering pointer operations much less efficient.

The Classic C solution to this is that the programmer had to know if
what he was testing against the null pointer was a pointer derived
from a fixed address somehow.  If so, and if the bit pattern of the
null pointer (usually all zeros) was a valid fixed address in that
context, the test against the null pointer was useless for determining
if the fixed address pointer was an invalid value.  In practice, this
restriction was no problem.  People who are careless with pointers to
fixed addresses receive little sympathy from any quarter.
-- 

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeffrey at algor2.ALGORISTS.COM or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090