From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e95e8407f65e1cfb
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-06-19 10:11:02 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone1.gnilink.net!spamfinder.gnilink.net!nwrddc04.gnilink.net.POSTED!53ab2750!not-for-mail
From: "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>
Newsgroups: comp.lang.ada
References: <mailman.1024335422.31035.comp.lang.ada@ada.eu.org>
 <3d0e5750_2@news.bluewin.ch>
 <ba162549.0206181116.7649f34d@posting.google.com>
 <3d0fb5eb_3@news.bluewin.ch> <3D10952F.17A62CCF@despammed.com>
Subject: Re: Look what I caught! was re:Ada paper critic
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <FW2Q8.893$iG4.643@nwrddc04.gnilink.net>
Date: Wed, 19 Jun 2002 17:11:01 GMT
NNTP-Posting-Host: 141.157.176.41
X-Complaints-To: abuse@verizon.net
X-Trace: nwrddc04.gnilink.net 1024506661 141.157.176.41 (Wed,
 19 Jun 2002 13:11:01 EDT)
NNTP-Posting-Date: Wed, 19 Jun 2002 13:11:01 EDT
Xref: archiver1.google.com comp.lang.ada:26405
Date: 2002-06-19T17:11:01+00:00
List-Id: <comp.lang.ada>

Actually, what the C standard says is that if you have a pointer just after
the end of an array, then the result of dereferencing that pointer is
"unpredictable". Such dereferences can cause segmentation fault, trash some
other memory, or do nothing at all. Any of these outcomes is consistent with
the standard. It's up to the programmer to avoid this behaviour.

Really, all the standard requires is that the compiler can generate a
pointer (not a corresponding object!) just past the right end of the array.
In others words, if we define

    PLANET solar_system[ 9 ];
    PLANET *past_pluto = solar_system + 9;

Then all the standard requires is that past_pluto can be computed, and that
it will compare correctly with pointers to other elements in solar_system,
e.g.

    ( past_pluto > solar_system + 0 ) &&
    ( past_pluto > solar_system + 1 ) &&
    ( past_pluto > solar_system + 2 ) &&
    ...
    ( past_pluto > solar_system + 8 )

That's all that's required. Access *past_pluto, and you're on your own.

Also, the standard only requires a valid pointer to the point just after the
end of an array; no similar rule applies to the beginning of the array. For
example, if you declare

    PLANET *before_mercury = solar_system - 1;

then the standard does NOT require that before_mercury compare meaningfully
with the addresses of the solar_system elements. Of course, the result of
dereferencing before_mercury is unpredictable.