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