Re: Finalization and Garbage Collection: a hole in the RM?

[bobduff@world.std.com (Robert A Duff)]

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