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

Jeffrey Kegler jeffrey at algor2.algorists.com
Thu Sep 7 06:06:10 AEST 1989


In article <10947 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <1989Sep6.052228.17374 at algor2.algorists.com> jeffrey at algor2.UUCP (Jeffrey Kegler) writes:
>>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.
>
>I've already explained how an implementation could provide a null
>pointer anyway, by using a datum in the run-time library whose address
>would be used for null pointers.

Sorry to have missed the original explanation.  I watch for Doug's
postings, but this one of his clarifications slipped by me.

Followup question: Must the dummy datum above be handled in some way
(such as preceding it with another dummy) that guarantees it is not
one past the end of any array?  It makes sense to me that it should,
but the standard does not seem to require this of a conforming
implementation.  The standard guarantees the pointer to an object will
not compare equal to the null pointer (3.2.2.3), but is the pointer
one past the end of the array a pointer to an object?  Not, IMHO, by
the definition of object in 1.6.

The situation where a loop incrementing a pointer through an array
contains a test of that pointer against the null pointer must be
reasonably familiar to Classic C programmers.  (The test against the
null pointer might be to test for uninitialized pointers, or some
error condition might set the pointer to null.)  Must the special case
of the pointer one past the end of the array being compared to the
null pointer be guarded against to be strictly conforming?  Again, yes,
as far as I can discern.

The standard requires that arithmetic with a pointer one past the end
of an array not overflow (3.3.6), and suggests that this be
implemented by there actually being a physical object at that place
(Footnote 43) but does not seem to require such an object.
-- 

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



More information about the Comp.lang.c mailing list