references to dereferenced null pointers
Kent Williams
williams at umaxc.weeg.uiowa.edu
Fri Mar 16 00:30:43 AEST 1990
In article <16179 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
>In article <1990Mar14.164539.23685 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>>There is absolutely nothing wrong with having a pointer representation in
>>which the bit pattern for a null pointer is not all zeros... except that
>>there are a lot of old, badly-written programs which will break. Thus my
>>earlier comment that it is valid but unwise.
>
>Note that "p = 0", "p == 0", "!p", "char *f() { return 0; }" are *not*
>examples of such badly-written code; they may be bad style, but the compiler
>is required to generate correct code involving a true null pointer.
The bottom line in actual practice is that if NULL isn't a binary object
of all zero bits, you can get into trouble porting programs. Using 0 and
NULL interchangebly is an unfortunate but common practice -- see code
examples in Stroustroup's C++ book -- many assignments of 0 to
pointers.
In order to port a program to a not-all-zero-bits-NULL architecture
would be aided by a compiler that would flag ALL assignments of
non-pointer constants to pointer variables. This wouldn't solve all
problems, since you can have a function like:
void assign_int_to_pointer(void **x, int y) { *x = (void *)y; }
Then your compiler would have to generate RUN-TIME checks of values
passed in.
To muddy the waters further, It isn't uncommon (and not terribly
unportable) to use a set of small integral constants, say 0 .. 10 as
sentinel values assigned to pointers, e.g.
switch((int)ptr) {
case 0: do0(); break;
case 1: do1(); break;
.
.
.
default:
it_really_is_a_pointer(ptr);
}
When discussing these issues, you do have to take into account actual
practice, whether actual practice is a good idea in the final analysis
or not.
--
Kent Williams "We're One! All One! Exceptions Eternally?
williams at umaxc.weeg.uiowa.edu None! Absolutely None!" - Dr. Bronner's Soap
More information about the Comp.lang.c
mailing list