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=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Tue, 07 Jul 2015 08:49:56 +0000
From: Matthias-Christian Ott <ott@mirix.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Dynamic allocation in the predefined language environment
References: <559a623d$0$293$14726298@news.sunsite.dk>
	<873811cre5.fsf@theworld.com>	<559a8d12$0$297$14726298@news.sunsite.dk>
 <87y4itbb0z.fsf@theworld.com>
In-Reply-To: <87y4itbb0z.fsf@theworld.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID: <559b9223$0$297$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 149.222.160.172
X-Trace: news.sunsite.dk
 DXC=GG:HPE@=KJab>:U6jKdTQlYSB=nbEKnkkkEDgFbcTNFm?QB<NW[Fj6f@2>B4OQc1?n9S2C>Lo?V]ol=nAi?5m[BcEU7Un5^kXZi
X-Complaints-To: staff@sunsite.dk
Xref: news.eternal-september.org comp.lang.ada:26677
Date: 2015-07-07T08:49:56+00:00
List-Id: <comp.lang.ada>

On 06/07/15 14:45, Bob Duff wrote:
> Matthias-Christian Ott <ott@mirix.org> writes:
> 
>> It could be implemented in C or assembly language and than it could
>> definitely crash.
> 
> Yes, it could be implemented in any language.  But it still has to be
> implemented correctly.  If it crashes, then it's not a conforming
> implementation of Ada.  (And of course, "conforming implementation of
> Ada" is synonymous with "implementation of Ada"!)
> 
> If you think the RM says otherwise, then either you are misunderstanding
> the RM, or else the RM has an error.  The latter is possible, but for
> sure the INTENT of the RM is that running out of memory raises
> Storage_Error, and does not "simply crash".
> 
> I mean, consider a simple addition:
> 
>     X + Y
> 
> The RM requires this to compute the sum of X and Y, or raise
> Constraint_Error on overflow (or (unlikely) raise Storage_Error --
> anything can raise Storage_Error).  The implementer doesn't get to say,
> "Well the RM doesn't specify HOW '+' is implemented, and I'm choosing to
> implement it wrong."

You have fully convinced me.

>> ...The point is: If the standard specifies how to
>> implement a package, you have to assume anything when reasoning about
>> the correctness of code.
> 
> I don't understand that sentence.  Are you missing a "not" or something?

Yes.

- Matthias-Christian