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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6f248223d81c2ffc
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Finalization and Garbage Collection: a hole in the RM?
Date: 1996/09/06
Message-ID: <DxBJ4C.FJy@world.std.com>#1/1
X-Deja-AN: 178894713
references: <mazzanti-0609960944120001@mac-mazz.iei.pi.cnr.it>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-09-06T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <mazzanti-0609960944120001@mac-mazz.iei.pi.cnr.it>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>Other aspects, instead, give to implementations the freedom the change
>or extend the normal semantic model, or the freedom to complete some
>unspecified aspects of the normal semantic model with erroneousness.
>And these are the best candidates for potential erroneous executions.
>(e.g. M(14): The operations on "nonstandard integer types"  or

Highly unlikely to be defined as erroneous.

>      M(38): The consequences of violating limitations on Restrictions
>              pragmas.)

Very well might be defined as erroneous.

>They are not many, I counted only 13 of them.
>[ M(4,10,14,15,21,38,42,44,52,58,77,81,85) ]
>
>A third group, finally, allows a function call to return an
>"implementation-defined" result [M(20,40,86,87,123,124,127,128,131)].
>(e.g. M(123): The result of a floating point arithmetic operation in 
>              overflow situations, when the Machine_Overflows attribute 
>              of the result type is False. 
> or  M(86) The result of the Task_Identification.Image attribute.)
>
>The erroneousness of the program might be affected if the implementation
>were allowed to return an "abnormal result".
>Is this  possibility allowed by the RM, or the fact that some value
>MUST be returned, even if implementation-defined, can be seen as
>automatically ruling out the possibility or returning an abnormal 
>value (which would probably be erroneous by itself).?

I think the impl-def result has to be a valid, non-abnormal value of the
type.

>In other words: can a function required to return a (implementation
>defined) result, directly cause an erroneous execution?

No, I don't think so.

- Bob