Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: ANSI C, hardware protection, out-of-bounds pointers
Keywords: ANSI C, hardware protection, out-of-bounds pointers
Message-ID: <10998@smoke.BRL.MIL>
Date: 9 Sep 89 01:33:08 GMT
References: <427@maytag.waterloo.edu> <867@hadron.UUCP> <10970@smoke.BRL.MIL> <868@hadron.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <868@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
>Erk.  You're right.  On the other hand (since stacks don't HAVE to be
>at the end of data space), an array could also abut the end of data
>space, and thus last+1 becomes NULL.  Is there anything forbidding
>that?

Yes.  A conforming implementation must ensure that that does not occur.
It's easier than for first-1, because a single extra storage word of slop
will suffice no matter how large the array member.

>For that matter, is there anything IN THE STANDARD that says first-1 is
>illegal?  (Besides the general fact that it's bad practice, of course.)

Yes, although not in those exact words.  Pointers to nonexistent objects
are not valid in strictly conforming programs, with an explicit exception
made for last+1 pointers (so long as no attempt is made to access what is
pointed to by one of them).