Null pointers

[Dave Thompson]

- Most implementors use all-bits-zero for internal null pointers.
It is usually the easiest thing to do, <snip>

- Many machines without virtual memory, and even some with, have
ROM or RAM at physical address 0.

The IBM S/360 architecture has various special stuff in low memory,
like old and new PSW's for various interrupts, although I don't recall
if any of them are at exactly 0. And thus so must its compatible
descendants (370, 390, and "z" series) in real mode, which ISTR IBM as
usual calls by some more officious name like "translation disabled".
And for multiprocessor machines, even with virtual memory off -- or
nonexistent? were there MP 360s? I don't recall -- they have a kludge
where page zero is switched with some other page that can be different
for each processor. Bleah.

Though I don't think there was ever a C on those machines (or at all?)
before 370s and virtual memory.

- C implementations that use all-bits-zero for all their internal
null pointers *and* that have useable RAM at address 0 must
make sure not to put any C object or function at address zero,
which is typically easily achieved by putting some "non-C"
thing there, such as startup code or a "shim".

Or, on "classic" (legacy) Tandem^WCompaq^WHP NonStop, which has
separate code and data address spaces, data address 0 is always used
for data internal to the run time library, specifically a pointer to
the "run unit control block", never a user object (variable). On this
implementation if you store through null, or fetch through null and
use it as a pointer to store at or near -- e.g. (mis)use 0 as a struct
foo * * or any_t (* *)[N] -- subsequently various C runtime stuff esp.
stdio which depends on data in or more often pointed to by the RUCB
malfunctions in bizarre and sometimes spectacular ways.

- David.Thompson1 at worldnet.att.net

 

[Dan Pop]

In C90 it was _not_ the case. There was _no_ rule in C90 that said that
casting constant 0 to any pointer type produced a null pointer.

It was implied by another rule:

If a null pointer constant is assigned to or compared for equality
to a pointer, the constant is converted to a pointer of that type.
Such a pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function.

The semantics of assignment include an implicit conversion. There is no
good reason to assume that the *same* conversion, when performed
explicitly, generates a different result.

Dan

 

[Dan Pop]

Because I have no idea what is actually at location 0 and what it
does, and no interest in finding out. I expect reading to be
non-harmful to my system.

Any good reason for such an expectation?

On most Unix systems (AIX is one of the exceptions), the behaviour is:

fangorn:~/tmp 15> cat test.c
#include <stdio.h>
#include <string.h>

int main()
{
char *p;
memset(&p, 0, sizeof p);
printf("%d\n", *p);
}
fangorn:~/tmp 16> gcc test.c
fangorn:~/tmp 17> ./a.out
Segmentation fault

Note that this is the *portable* way to access location zero. The
result of converting an integer to a pointer is implementation-defined
and need not be a mere reinterpretation of a bit pattern.

Dan