What machines core dump on deref of NULL?

[Joshua Osborne]

In article <1990Jun29.132304.12550 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>  It would seem to me that a simpler solution to the embedded processor
>problem than requiring a non-standard C compiler in order to write code
>for one would be to not have any physical memory at address 0, or to put
>program memory there (since, unless the program is self-modifying, it
>should never have to access its own memory, excluding perhaps function
>pointers).

Most processers treat the first N bytes of memmory diffrently.  The 6510
uses the first 2 bytes as an I/O regester (which implments bank switching on
the C=64).  The 680x0 uses the first N bytes for address of traps, interupt
vectors, and something else (is it the value of A7 after cold boot?).  They
are things that an OS would need to change, not a user.  They are most
likely things that standard system functions like malloc() never return
pointers to.  So NULL could still be returned as an error indicator from
functions that return pointers.  On systems with an OS only the OS should be
able to write to NULL (the Atari ST only lets programs write to the first 2 or
4K when the S bit is on).  If a system has no OS (non-hosted env) then a C
program may well have to write to location 0, which may well be NULL, but it
is still not a valid pointer to "normal" memmory.  Also there may be *no*
invalid addresses, a CPU with 16 bit address space, and 64K has no invalid
addresses (unless it has alignment restrictions...).
-- 
           stripes at eng.umd.edu          "Security for Unix is like
      Josh_Osborne at Real_World,The          Mutitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
"Don't try to change C into some nice, safe, portable programming language
 with all sharp edges removed, pick another language."  - John Limpert