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


Robert said:

" In the context of discussing whether bounded errors are predictable
 or not. But there is a HUGE difference between
implementation-defined
 and a bouned error. If something is implementation defined, then
 Annex M must specify its behavior, and the behavior is entirely
 predictable.
 However, reading paragraphs 9-11 here, I agree there is a lot of
 confusion over what is a bounded error, and what is implementation
 defined, and the RM does not seem to recognize the HUGE difference I
 mention above :-) 
 Bob (Duff), can you sort out the intention here, para 9 seems to say
 that evaluating the value of an object with an invalid
 reprsentatoin is a bounded error, and para 11 seems to say that is
 implementation defined. Even for someone who *is* a native speaker
 and reader of English, this is completely confusing to me :-) "


I cannot speak for the RM authors (hence cannot guarantee for the
correcntess of the interpretation) but I can present my
interpretation of the fact, as an "external" view (hence not 
influenced by unwritten knowdegde or discussions, nor by any strong 
reliance on the "normal English meaning of terms").

After all, the picture seems to me rather consistent:

"implementation-defined" aspects are of two types:

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).
Others, 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 even with 
erroneousness (e.g.M(38)).
In any case, the particular choice selected by the implementation
MUST BE DOCUMENTED.

Clearly, if an implementation writes that a certain
implementation-defined action is erroneous, the execution can still
be "(totally) unpredictable", even if the possible behavior has been
"documented" by the implementation.

Bounded Errors, instead, do not carry the possibility of 
"(totally) unpredictable" (i.e. "erroneous") behavior. 
What might actually happen in these cases, is required to be
documented only if Annex H is supported [H.2(1),M(33)]).
Usually, the RM explicitly defines a well defined set of alternatives
for the possible program behaviour in presence of bounded errors. 

In a few cases, however, the RM does not explicitly define this set
of alternatives, but lets the implementation to define it (as an
implementation-defined aspect).  Very consistently, however, requires
that all these implemention-defined alternatives to be "well
defined", keeping out of the door the possibility that an
implemenation reintroduces erroneous executions within
bounded-errors.

Conclusions:

Bounded Errors:  
    Are errors.
    Possible behavior usually defined the RM, in a few cases
      defined by the implementation. 
    Behaviour is in any case not erroneous.
    Actual behaviour documented if Annex H is supported.

Implementation Defined: 
    Are not necessarily errors.
    Possible behavior sometimes explicitly defined by the RM,
      sometimes defined by the implementation. 
    In certain cases, the behaviour can also be erroneous 
           (in which case we have an error) .
    Actual behaviour always documented.


Franco Mazzanti