What machines core dump on deref of NULL?

[Matthew T. Russotto]

In article <418 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>
>And on page 192 of my C bible I find the paragraph:
>	The compilers currently allow a pointer to be assigned to an integer,
>	an integer to a pointer, and a pointer to a pointer of another type.
>	The assignment is a pure copy operation, with no conversion.  This
>	usage is nonportable, and may produce pointers which cause address
>	exceptions when used.  However, it is guaranteed that assignment of
>	the constant 0 to a pointer will produce a null pointer distinguish-
>	able from a pointer to any object.
>
>The trouble with this statement is that I've never seen a C compiler
>that implements it.  On extant processors, it is simple to prove that
>it can't be implemented.  If you examine any of the current commercial
>processors (68xxx, 8xx86, SPARC, MIPS, PDP11/VAX, etc.), you quickly
>learn that all of them have the property that there is no bit pattern
>that is guaranteed to cause a fault when used as an address.

Why does that statement mean that you can't dereference NULL without a fault?
Distinguishable in this sense just means you can use tests like

p=0;
if (p == &someobject)
	code();
else
	othercode()

which will always fail (it probably also means that malloc, etc, can never
allocate an object at 0)

All code which attempts to reference objects at ANY specific memory location
(includein kernel code which references interrupt vector tables, etc) will
be nonportable-- that is implied by that statement also.
--
Matthew T. Russotto	russotto at eng.umd.edu	russotto at wam.umd.edu
][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
		Hey!  Bush has NO LIPS!