What machines core dump on deref of NULL?
Doug Gwyn
gwyn at smoke.BRL.MIL
Wed Jul 4 07:57:27 AEST 1990
In article <412 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>In article <13226 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>> To the contrary, this merely prevents genuine bugs from being caught
>> as soon as they would be were dereference of a null pointer to trap.
>> Dereferencing a null pointer is a serious BUG in any application and
>> can indicate an algorithmic error that should be tracked down before
>> it is too late.
>Hey, wait just a minute here. I can't let such an erroneous error go
>unchallenged! Dereferencing a null pointer is quite definitely *not*
>an error, bug, mistake, or any other pejorative, in a great many sorts
>of applications.
It is ALWAYS an error, since a null pointer by definition does not
point to valid storage.
>The trouble with generalizing to all C code is that C outgrew Unix
>about a decade ago.
What does that have to do with anything? Indeed, in many UNIX
implementations you could actually get away with dereferencing a null
pointer. It has taken years to stamp out most such abuses in code
originally developed under such UNIX implementations. This argues in
exactly the opposite direction from how you must have intended.
>... Such embedded, standalone programs not only can, but are required
>to access all of physical memory, including address zero.
Data memory address zero has no necessary relation to a null pointer.
It is tricky to code an access to such an absolute address in C,
because if you write something like "(foo *)0" you have specified a
null pointer of type "pointer to foo", not a pointer to a "foo" object
stored at machine location zero. (Back in the old days of UNIX, there
was no need to distinguish between these, but now there is a definite
distinction.) There are correct ways to code the intended effect in C,
which I will leave as an exercise for you to work on, but it should be
noted that it is highly likely that a compiler for such a target
environment does use the same representation for both a null pointer
and a pointer to something at location zero, in which case you can
continue to use a naive approach to coding such operations. However,
you then cannot distinguish between a valid pointer to such an address
and a null pointer, which could cause other algorithmic problems.
There are a variety of ways that a C implementation can represent
null pointers using other than all-0 bit patterns. I won't bore you
with implementation details, but you should be aware that such methods
exist and may be used by the C implementation if access to machine
address zero was considered important by the implementor.
More information about the Comp.unix.wizards
mailing list