Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!gatech!purdue!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: Invalid Pointers (was Re: Referencing NULL pointers)
Message-ID: <35077@bu-cs.BU.EDU>
Date: 21 Jul 89 16:34:06 GMT
References: <20245@adm.BRL.MIL> <4348@eos.UUCP> <34785@bu-cs.BU.EDU> <12872@bloom-beacon.MIT.EDU>
Organization: Boston U. Comp. Sci.
Lines: 81


>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:

The issue is a *unique* spot to test against versus one which is
guaranteed to cause a core dump or some other fault, perhaps. Although
in theory a pointer of zero should cause some sort of fault we all
should know by now that some of the most popular unix platforms will
treat it as legally as any other address, does the person want the
theoretical answer or one which will work for his/her software on a
variety of platforms? In fact as I remember this is exactly what the
original question was alluding to, he was well aware of using a zero
pointer but felt he needed some alternative (he was using -1.)

Some people suggested just calling malloc(n) and using that and that
indeed is equivalent to my suggestion other than set-up costs (why not
just set it up statically at load time?) The advantage to this sort of
approach is you can have more than one of them (eg. to be able to type
the invalid pointer.)

I believe the only sure way to get a pointer which is guaranteed to
cause a fault on a wide variety of platforms if de-referenced is going
to involve machine-dependent ifdef's in a header, it will vary from
machine to machine.

Obvious attacks are 0 on many (but not all) systems, a pointer into
text space on others (eg. the address of a function), even that
depends on certain load options being used but we'll assume that's
under control of the author, setting some magic bit (eg. pointing into
the wrong P space on a VAX), others?

In fact on some machines there may be no pointer guaranteed to produce
a fault when dereferenced (at least not without changing the operating
system which I am sure someone here will suggest as a counter-example,
wrongo, not w/in the stated constraints.) I believe an example of that
would be a PDP-11 with separate I&D space and all data space (64K)
legally allocated, NOT an unusual situation (tho PDP-11s are somewhat
unusual in this day and age.) The S/370 using 24 bit addressing may be
another example depending on the host O/S, same for a '286? (not
exactly rare and peculiar machines.) Trying to write into the space of
course makes the problem easier, but most would like an address which
faults if read (can't just destroy memory to see if a pointer is
valid.)

It's an interesting question and repeating zero adds nothing.


-- 
	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
Internet: bzs@skuld.std.com
UUCP:     encore!xylogics!skuld!bzs or uunet!skuld!bzs