Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!umd5!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: Invalid pointer addresses
Keywords: NULL, pointer
Message-ID: <8453@smoke.ARPA>
Date: 8 Sep 88 05:18:27 GMT
References: <12088@steinmetz.ge.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 31

In article <12088@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  I recently proofread a manual which stated that even calculating the
>value of an invalid address could cause a memory fault. I read this to
>mean that ...

Yes, that's right.  This problem can occur on segemented architectures
(the 80*86 is not the only one!) and on tagged (or capability-based)
architectures.

>  An example in point are the machines which will fault if you try to
>dereference a NULL pointer. Simply having the value NULL doesn't cause a
>problem. Is there a portion of dpANS which states that this is/isn't
>allowed, or that it's implementation dependent?

A null pointer (which is written as 0 or (some_type *)0, depending on
context, also sometimes as NULL for convenience) is part of the C
language according to the dpANS.  Dereferencing it leads to undefined
behavior.  Computing a pointer to a nonexistent object (other than
just past the end of an array) is also undefined behavior.  [This is
from memory; certainly the dpANS does not promise that it will work
for all conforming implementations.]

>Seems like "common practice" to me,

Lots of nonportable constructs are commonly encountered.

> and portable, ...

No, sorry.  It happens to work (accidentally) in many cases on many
implementations, but since it can fail on some and is not guaranteed,
it is not "portable".