Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.std.c
Subject: Re: Out-of-bounds pointers
Message-ID: <2322@munnari.oz.au>
Date: 7 Oct 89 09:56:35 GMT
References: <1009@mtxinu.UUCP> <12570028@hpclwjm.HP.COM> <868@crdos1.crd.ge.COM> <217@bbxsda.UUCP>
Sender: news@cs.mu.oz.au
Lines: 41

In article <868@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>|  Doug Gwyn:
>|  > It's not even "legal" to compute an invalid address, whether or not
>|  > it is dereferenced.
>  While this is obviously true, I have never understood the rationale of
>this decision. Given that (a) there are existing programs which do this,
>for reasons other than sloppy programming, (b) most implementations
>happily allow this, and (c) if you are allowed to declare an auto
>pointer at all then obviously the hardware supports uninitialized
>pointers, I fail to see what benefit is gained.

(b) The implementations which allowed it don't have to stop allowing it.
(c) Not so; the compiler might quietly initialise every pointer variable
    to a valid address.  (Auto variables might be allocated by pushing
    the current value of the SP on the stack, for example.)

In article <217@bbxsda.UUCP>, scott@bbxsda.UUCP (Scott Amspoker) writes:
> We just got through an *extremely* long thread in comp.lang.c regarding
> this issue (it eventually just fizzled out).  ... For example, the
> 286/386 CPUs will trap if you load just any 'ol garbage into a segment
> register.  Since handling a pointer variable might cause such a load
> operation you could get a trap even though you did not de-reference the
> pointer.

I participated in that thread.  Basically it fizzled out because it was
quite clear that the restriction isn't going to go away, so there wasn't
any point in talking further.  But it also became clear that the 80286
and 80386 are *NOT* examples of the problem; you wouldn't do pointer
comparisons or pointer arithmetic in a segment register on an 80286
because you _can't_.

> Don't worry - all is not lost.  No one was able to come up with a real
> world example of something like this.

There is a practical case where this _is_ likely to come up.
C interpreters.  There are already C interpreters which do things like
checking that a pointer doesn't point to anywhere wild and that pointer
comparisons involve pointers into the same array.  It would not be
surprising if ANSI C interpreters make this check too.

You can, if necessary, make your array one element longer than you need.