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: mazzanti@iei.pi.cnr.it (Franco Mazzanti)
Subject: Re: Finalization and Garbage Collection: a hole in the RM?
Date: 1996/09/06
Message-ID: <mazzanti-0609960944120001@mac-mazz.iei.pi.cnr.it>#1/1
X-Deja-AN: 178831339
organization: IEI-CNR
newsgroups: comp.lang.ada
Date: 1996-09-06T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert A Duff said:

> Your best bet is to get the ascii version of the RM or AARM, and search
> in a text editor for "erroneous", "unspecified", "implementation
> defined", etc.  (I say "impl def", because it is theoretically possible
> for an implementation to take something that's implemenation defined,
> and define it to be erroneous.  In most cases, this is highly unlikely.
> You can probably tell by looking at each case whether or not its likely
> in practise.)

I have already done  that for "erroneous", (un, not)"specified",
"abnormal", and several others.  But no, I did not go through
implementation-defined aspects. I thought they cound not be transformed
by the implementation into erroneous executions ... You have opened
for me a new can of worms ...

> 
> Also, read 11.6.
> 

I already read this piece of cake many times, and still have to figure
out what it does really imply ... :-) 
I plan to reinvestigate that aspects soon.


> >For what I can see, according to [RM 1.1.4(18)]  (see below), there is
> >nothing "unpredictable" ("erroneous") in things being executed in
> >"arbitrary order".
> 
> Well, it depends how unpredictable you mean -- erroneous things are
> totally unpredictable, and can cause the program to behave outside the
> normal semantic model.  Bounded errors and arbitrary orders are only a
> little bit unpredictable (i.e. there's a well-defined set of
> possibilities).  Certainly *any* form of nondeterminism can cause
> trouble -- portability problems, programs that work with optimization
> turned off but not with optimization turned on, etc.  And it's worse in
> theory than in practise, since most compilers don't (for example) roll
> dice on every subprogram call to determine the order of parameter
> evaluation.
> 
> Thankfully, Ada has far fewer cases of totally unpredictable behavior
> than certain other palindromic languages.  ;-)  And Ada 95 eliminates one
> of the worst cases of erroneousness in Ada 83 -- uninitialized
> variables.
> 
> - Bob

I agree, but currently I am just trying to understand only the "totally
unpredictable" aspects. That is enough for now.

Returning to implementation-defined aspects, of the 136 cases mentioned
in Appendix M, most of them give  to implementations some freedom
in supporting some aspect, but without affecting the program run-time
semantics, or affecting the run-time semantics in a well defined way.
(see E.g. M(34) the order of elaboration of library items).

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
      M(38): The consequences of violating limitations on Restrictions
              pragmas.)
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).?

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

Franco