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/02
Message-ID: <mazzanti-0209961050000001@mac-mazz.iei.pi.cnr.it>#1/1
X-Deja-AN: 177949413
organization: IEI-CNR
newsgroups: comp.lang.ada
Date: 1996-09-02T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert A Duff wrote:
>
> >I am trying to write a roadmap to erroneous executions and other
> >unpredictabilities in Ada95, so for me it would be important to find all
> >the possible issues of this kind.
>
> Are you interested in erroneous/unpredictable stuff in general, or are
> you interested specifically in issues related to garbage collection?

I am interested in erroneous/unpredictable(in the sense of the RM, which is
almost a synonym of "erroneous") stuff in general.

> The index of the RM and AARM contains entries for "erroneous" and
> "bounded error" that will let you track down all the cases.

"Bounded Errors" are not considered by the RM (not from me) cases of
true "unpredictability". A program with bounded errors is not erroneous.

The entry "erroneous" in the RM (and AARM) Index does not allow to track
down all the cases. We have to look also at the entries "abnormal" and
"unspecified".  Even so, there is a small aspect which is still non captured
([RM 13.13.2.(35)]).  Finally, we should have to consider also any
possible language "holes" (i.e. I cannot take for granted that the RM is
"perfect").

> Another
> source of unpredictability is when the run-time semantics says
> "arbitrary order".  I don't think that's in the index, but you could use
> an editor to search the ascii version of the RM.

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".

[RM 1.1.4(18)]:
"18   Whenever the run-time semantics defines certain actions to happen in an
arbitrary order, this means that the implementation shall arrange for these
actions to occur in a way that is equivalent to some sequential order,
following the rules that result from that sequential order.  When evaluations
are defined to happen in an arbitrary order, with conversion of the results
to some subtypes, or with some run-time checks, the evaluations, conversions,
and checks may be arbitrarily interspersed, so long as each expression is
evaluated before converting or checking its value.  Note that the effect of a
program can depend on the order chosen by the implementation.  This can
happen, for example, if two actual parameters of a given call have side
effects."

In any case, if you are interested in reviewing the draft version of the
document (when it will be ready), I would be happy to make it available to you
(or anybody else interested). Just let me know.

Franco

------------------------------------------------------------
   Dr. Franco Mazzanti
   Istituto di Elaborazione della Informazione
   Via S.Maria 46, 56126 Pisa, ITALY
   Tel: +39-50-593447/593400, Fax: +39-50-554342
   e-mail: mazzanti@iei.pi.cnr.it
------------------------------------------------------------