What machines core dump on deref of NULL?

[Scott Amspoker]

In article <412 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>                                          Such embedded, standalone
>programs not only can, but are required to access all of physical
>memory, including address zero.  The hardware says that something 
>particular resides at the bottom end of memory, and such a program 
>must access that byte/word/whatever, or it can't do its job.  If a 
>C compiler won't let me access that address, then I look for another 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>that was written by someone more competent.


Please re-read the thread.  We are not talking about a feature of the
C compiler but a feature of the host operating system.  If you are
running a standalone, absolute memory application then such error
traps would not apply.

>Of course, all C compilers already have a perfectly good tool for
>doing a run-time check for a null pointer:
>	if (p == 0 ) ...
>I use it a lot.  In particular, I introduce it all over the place
>in code that I'm porting from VAXen to other machines.  I suggest 
>that others try it.  It's a whole lot nicer than having your program
>bomb out on a SEGV.

Well, what if p==0?  continue?  abort?  I think posters on this thread
were refering to the situations where a null pointer should *not*, by 
definition, be present.  In which case, dereferencing a NULL would
indicate a bug that the programmer would wish to discover early in the
testing phase.  If the pointer in question could not be trusted (i.e.
passed by an outside library routine) then it would be prudent to
explicitly test it as you have shown.


-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott