Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Invalid Pointers (was Re: Referencing NULL pointers)
Message-ID: <12872@bloom-beacon.MIT.EDU>
Date: 21 Jul 89 03:00:39 GMT
References: <20245@adm.BRL.MIL> <4348@eos.UUCP> <34785@bu-cs.BU.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 32

In article <34785@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>A perfectly good solution is:
>
>	struct foobar no_foobar;
>	#define NO_FOOBAR (&no_foobar)
>
>being as no_foobar will be the only thing assigned this address it is
>unique and solves your problem.

struct foobar no_foobar;
#define NO_FOOBAR (&no_foobar)
struct foobar foo_array[50];
struct foobar *ptr;

...

ptr = &foo_array[0];
ptr = ptr - 1;

Now, the last line above is obviously not something that should be
encouraged :-), but fencepost errors of that type happen commonly
inside loops et al.  You can't assume that just because you've
allocated a particular spot in memory be declaring a variable to sit
in that spot, nothing else will ever try to access that spot.

The already-mentioned assignment of NO_FOOBAR to 0 is a better
solution.

Jonathan Kamens			              USnail:
MIT Project Athena				432 S. Rose Blvd.
jik@Athena.MIT.EDU				Akron, OH  44320
Office: 617-253-4261			      Home: 216-869-6432