Referencing NULL pointers
Kris Croes
croes at imec.uucp
Wed Jul 12 17:42:13 AEST 1989
In article <19367 at paris.ics.uci.edu> T.S. Hadley <hadley at icarus.ics.uci.edu> writes:
> ..
> char *s = (char *) 0, t[10];
> strcpy(t, s);
> ...
> /* or */
> ...
> TYPE *t = (TYPE *) 0; /* typedef struct { ... } TYPE; */
> if(t->field == 0)
> ...
> On my machine (sun) these statements causes segmentation violations
> during runtime.
As they should!!! DOMAIN and Ultrix e.g. do not give SGVIOL, and this is
a pitty because some nasty and hard to find bugs are usualy caused by
(unknowingly) doing these things.
> Apparantly, on other machines this is perfectly valid, since I see
> quite a lot of this in code created on certain non-sun machines.
VALID??? In my humble opinion this is as INVALID as it could be. NULL points to
nothing, and must not be dereferenced: consider a rather large struct xxx, then
xxx->last_field = something can scramble up your text segment,...
See quite a lot of this??? Give me ONE example of this (not written by yourself).
(PS: I recognise that in some rare cases (e.g. accessing video-memory in a PC) this
could be valid, but in any case it's no good programming practice)
> What can I do about it? Is there a flag on some C compiler to handle
> these situations? (gcc -fallow-null-pointer-referencing-idiocy :-)
I hope that there is not, maybe on DOMAIN and Ultrix there should be an option
to make the program crash if NULL is dereferenced!!!. (Yes, I have a very bad
experience with this)
> Grateful Thanks.
You're welcome.
K. Croes
--
--------
K. CROES - IMEC - Leuven - Belgium ..!prlb2!imec!croes
The Demon King bites in your leg and you feel weaker.
More information about the Comp.unix.wizards
mailing list