Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcvax!prlb2!kulcs!kulesat!imec!croes From: croes@imec.uucp (Kris Croes) Newsgroups: comp.unix.wizards Subject: Re: Referencing NULL pointers Message-ID: <541@imec.UUCP> Date: 12 Jul 89 07:42:13 GMT References: <19367@paris.ics.uci.edu> Reply-To: croes@imec.UUCP (Kris Croes) Organization: IMEC, INTERUNIVERSITY MICROELECTRONICS CENTER, BELGIUM Lines: 37 In article <19367@paris.ics.uci.edu> T.S. Hadley 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.