Finalization and Garbage Collection: a hole in the RM?

Finalization and Garbage Collection: a hole in the RM?

[Franco Mazzanti]

I could not find are rule describing what could/should happen when an
exception is raised by a Finalization routine called by the garbage
collector.  [RM 7.6.1.(14)] says that this is a bounded error, and this,
fortunately rules out any erroneous execution. But the list of the 
possible effects does not contain the case of Finalize being called
by a garbage collector. 

Should this be interpreted as if the garbage collector should act exactly
as any other Ada task, and handle in its own way any possible exception
raised by Finalize? 
[RM 13.12(6)] says something on the Garbage Collection, but in an a way that
does not seem to mandate at all the above point of view.

Missing something??

Franco Mazzanti  <mazzanti@iei.pi.cnr.it>
I.E.I. - C.N.R.

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

[Robert A Duff]

In article <mazzanti-2608961026160001@mac-mazz.iei.pi.cnr.it>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
[stuff about gc]

If you're interested in garbage collection, you should subscribe to the
gclist mailing list:

> Article 9782 of comp.compilers:
> From: johnl@iecc.com (John R Levine)
> Newsgroups: comp.compilers
> Subject: GC mailing list
> Date: 18 Feb 1996 23:03:05 -0500
> Organization: Compilers Central
> Lines: 22
> Approved: compilers@ivan.iecc.com
> Message-ID: <96-02-223@comp.compilers>
> NNTP-Posting-Host: localhost.iecc.com
> Keywords: GC, administrivia
> 
> I got enough interest in garbage collection to start a GC mailing list.
> 
> To join it, send a message to majordomo@iecc.com which contains:
> 
> 	sub gclist
> 
> To leave it once you join it, send a message that contains
> 
> 	signoff gclist
> 
> This list is currently open and unmoderated, though I reserve the right to
> eject persistently unruly contributors.  You have to join it before you can
> send messages to it; this makes the list harder to spam.
> 
> Regards,
> John Levine, comp.compilers moderator, johnl@iecc.com
> 
> 
> 
> --
> Send compilers articles to compilers@iecc.com,
> meta-mail to compilers-request@iecc.com.

Here's part of the message I got when I subscribed:

> Welcome to the Garbage Collection list.  This spin-off from the
> comp.compilers newsgroup discusses garbage collection in programming
> languages.  Both integrated garbage collection as in Lisp and "bolt
> on" collection as in conservative collectors for C are fair game.
> 
> This list is open to all and unmoderated, although the list owner
> reserves the right to eject persistently unruly contributors.  It
> currently is not available as a digest, although I'll add a digested
> form in the future if the list volume warrants.
> 
> All previous articles are available for FTP at ftp://iecc.com/pub/gclist/
> in a file called messages.
> 
> Regards,
> John Levine, johnl@iecc.com

- Bob

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

[Robert A Duff]

In article <mazzanti-2608961026160001@mac-mazz.iei.pi.cnr.it>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>I could not find are rule describing what could/should happen when an
>exception is raised by a Finalization routine called by the garbage
>collector. ...

There are many nasty interactions between garbage collection and
finalization.  What to do with exceptions is one of them.  Others are:
Since the gc is essentially running concurrently with the user's
task(s), how to prevent race conditions?  In what order should the gc
invoke finalization on garbage objects?  (If A points to B, you would
normally want B finalized first, but what about cycles?)  What happens
if some objects are found to be garbage, and then a finalizer resurrects
some of them, by planting some pointers to them in non-garbage objects?

This stuff was discussed extensively a while back on the gclist mailing
list, which I'll post about in another note.  I don't remember if the
exception issue was discussed.  There's an ftp site for copies of old
stuff.

One possible answer is that the exceptions get lost, as for a task.
This makes debugging rather painful.

Another possibility is to kill the whole program, trap into the
debugger, record the error in an error log, or whatever is appropriate
for catastrophic failures on your system.

Another possibility is to not collect finalizable objects.  This is
probably the easiest to implement -- the implementation will probably
attach all the finalizable objects to a per-task linked list, and the
garbage collector will naturally find them on the list, and assume
they're not garbage, unless the gc does something special (like treating
that list like Modula-3 weak pointers).  One possible rationale for this
attitude is, "Most finalization is for deallocating memory anyway, so if
you have gc, why bother?  The remaining finalization is for managing
things like file handles and so forth (i.e. pointers to things outside
the program), and these are mostly stack-allocated things anyway.  In
the rare cases when you have file handles living in heap objects, the
programmer has to worry about it.  Another possible rationale is that
having code that does stuff at unpredictable times is a pain to debug
anyway, so it's better not to mix gc and finalization.  After all, a gc
is supposed to be invisible, except for memory-usage and timing -- the
gc shouldn't go around calling procedures with side effects.  I'm not
sure whether or not I believe these arguments, but they have *some*
merit.

In any case, the design of Ada 95 does not answer your question, so I'd
say it's fair for the gc implementer to design a solution to the
problem.  There's always the cop-out of letting the user choose from
among several bad options.  ;-)

- Bob

P.S. Here's everything the AARM has to say about garbage collection:

7.6.1:

   24.o   Because Controlled and Limited_Controlled are library-level tagged
        types, all controlled types will be library-level types, because of
        the accessibility rules (see 3.10.2 and 3.9.1).  This ensures that
        the Finalize operations may be applied without providing any
        ``display'' or ``static-link.''  This simplifies finalization as a
        result of garbage collection, abort, and asynchronous transfer of
        control.

13.11.3 Pragma Controlled

1   [Pragma Controlled is used to prevent any automatic reclamation of
storage (garbage collection) for the objects created by allocators of a given
access type.]


                                   Syntax

    2   The form of a pragma Controlled is as follows:


3     pragma Controlled(first_subtype_local_name);

        3.a   Discussion:  Not to be confused with type Finalization.-
        Controlled.


                               Legality Rules

4   The first_subtype_local_name of a pragma Controlled shall denote a
non-derived access subtype.


                              Static Semantics

5   {representation pragma [Controlled]} {pragma, representation
[Controlled]} A pragma Controlled is a representation pragma {aspect of
representation [controlled]} {controlled (aspect of representation)} that
specifies the controlled aspect of representation.

6   {garbage collection} Garbage collection is a process that automatically
reclaims storage, or moves objects to a different address, while the objects
still exist.

        6.a   Ramification:  Storage reclamation upon leaving a master is not
        considered garbage collection.

        6.b   Note that garbage collection includes compaction of a pool
        (``moved to a different Address''), even if storage reclamation is
        not done.

        6.c   Reason:  Programs that will be damaged by automatic storage
        reclamation are just as likely to be damaged by having objects moved
        to different locations in memory.  A pragma Controlled should turn
        off both flavors of garbage collection.

        6.d   Implementation Note:  If garbage collection reclaims the
        storage of a controlled object, it should first finalize it.
        Finalization is not done when moving an object; any self-relative
        pointers will have to be updated by the garbage collector.  If an
        implementation provides garbage collection for a storage pool
        containing controlled objects (see 7.6), then it should provide a
        means for deferring garbage collection of those controlled objects.

        6.e   Reason:  This allows the manager of a resource released by a
        Finalize operation to defer garbage collection during its critical
        regions; it is up to the author of the Finalize operation to do so.
        Garbage collection, at least in some systems, can happen
        asynchronously with respect to normal user code.  Note that it is not
        enough to defer garbage collection during Initialize, Adjust, and
        Finalize, because the resource in question might be used in other
        situations as well.  For example:
6.f         with Ada.Finalization;
            package P is

6.g             type My_Controlled is
                    new Ada.Finalization.Limited_Controlled with private;
                procedure Finalize(Object : in out My_Controlled);
                type My_Controlled_Access is access My_Controlled;

6.h             procedure Non_Reentrant;

6.i         private
                ...
            end P;

6.j         package body P is
                X : Integer := 0;
                A : array(Integer range 1..10) of Integer;

6.k             procedure Non_Reentrant is
                begin
                    X := X + 1;
                    -- If the system decides to do a garbage collection here,
                    -- then we're in trouble, because it will call Finalize on
                    -- the collected objects; we essentially have two threads
                    -- of control erroneously accessing shared variables.
                    -- The garbage collector behaves like a separate thread
                    -- of control, even though the user hasn't declared
                    -- any tasks.
                    A(X) := ...;
                end Non_Reentrant;

6.l             procedure Finalize(Object : in out My_Controlled) is
                begin
                    Non_Reentrant;
                end Finalize;
            end P;

6.m         with P; use P;
            procedure Main is
            begin
                ... new My_Controlled ... -- allocate some objects
                ...  forget the pointers to some of them, so they become garbage
                Non_Reentrant;
            end Main;

        6.n   It is the user's responsibility to protect against this sort of
        thing, and the implementation's responsibility to provide the
        necessary operations.

        6.o   We do not give these operations names, nor explain their exact
        semantics, because different implementations of garbage collection
        might have different needs, and because garbage collection is not
        supported by most Ada implementations, so portability is not
        important here.  Another reason not to turn off garbage collection
        during each entire Finalize operation is that it would create a
        serial bottleneck; it might be only part of the Finalize operation
        that conflicts with some other resource.  It is the intention that
        the mechanisms provided be finer-grained than pragma Controlled.

7   If a pragma Controlled is specified for an access type with a standard
storage pool, then garbage collection is not performed for objects in that
pool.

        7.a   Ramification:  If Controlled is not specified, the
        implementation may, but need not, perform garbage collection.  If
        Storage_Pool is specified, then a pragma Controlled for that type is
        ignored.

        7.b   Reason:  Controlled means that implementation-provided garbage
        collection is turned off; if the Storage_Pool is specified, the pool
        controls whether garbage collection is done.


                         Implementation Permissions

8   An implementation need not support garbage collection, in which case, a
pragma Controlled has no effect.


                         Wording Changes From Ada 83

        8.a   Ada 83 used the term ``automatic storage reclamation'' to refer
        to what is known traditionally as ``garbage collection''.  Because of
        the existence of storage pools (see 13.11), we need to distinguish
        this from the storage reclamation that might happen upon leaving a
        master.  Therefore, we now use the term ``garbage collection'' in its
        normal computer-science sense.  This has the additional advantage of
        making our terminology more accessible to people outside the Ada
        world.

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

[Franco Mazzanti]

> >I could not find are rule describing what could/should happen when an
> >exception is raised by a Finalization routine called by the garbage
> >collector. ...


> One possible answer is that the exceptions get lost, as for a task.
> This makes debugging rather painful.
> ...

> Another possibility is to kill the whole program, trap into the
> debugger, record the error in an error log, or whatever is appropriate
> for catastrophic failures on your system.
> ...

> 
> Another possibility is to not collect finalizable objects.  
> ...

> In any case, the design of Ada 95 does not answer your question, so I'd
> say it's fair for the gc implementer to design a solution to the
> problem.  There's always the cop-out of letting the user choose from
> among several bad options.  ;-)
> 
> - Bob
> 

Well, I understand that a clean integration of garbage collection in Ada
requires the solution of several difficulties.

What is really scaring me, are not just the problems inherent to GC,
but the fact that there are hidden "holes" in the language definition,
and that the effect of a program falling in this "holes" is completely
undefined.

Are there any other holes like this one are hiding there?

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.

Anybody knows?


Franco Mazzanti

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

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

[Robert A Duff]

In article <mazzanti-3008961532260001@mac-mazz.iei.pi.cnr.it>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>Are there any other holes like this one are hiding there?
>
>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?

The index of the RM and AARM contains entries for "erroneous" and
"bounded error" that will let you track down all the cases.  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.

As for garbage collection, I don't know of any other major pitfalls
(other than interactions with finalization, I mean), and I already
posted the small amount of discussion in the AARM.  Another issue is
that you can point into the middle of objects (via renamings, and via
'Access on components).  So the last remaining pointer to an object
might actually point into the middle of it, or to a slice of it.  You
can point to non-existent stuff -- e.g. use 'Unchecked_Access to create
a pointer to a local variable, then return from the subprogram, leaving
the pointer pointing past the stack top.  This is not an error (assuming
the pointer is never referenced later), but the pointer is still there
for the gc to trip over.  A still-running task is not garbage, even if
there are no pointers to it, since it can reach out and do things.
Interactions between tasking and gc in general (e.g. you can't just run
the garbage collector when the user program is doing a "new", because
some other task might be doing something else).  Etc.  But these all
seem like solvable problems.

- Bob

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

[Franco Mazzanti]

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

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

[Robert A Duff]

In article <mazzanti-0209961050000001@mac-mazz.iei.pi.cnr.it>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>"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").

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

Also, read 11.6.

>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

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

[Robert Dewar]

Franco said

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

Well anyone can use language any way they like, but in the normal English
meaning of the word unpredictable (which is the proper one to be using,
since unpredictable is not  technical term), of course bounded errors
result in unpredictable program execution, in that you cannot predict
what will happen. 

There is a very deliberate distinction drawn in the RM between 
non-deterministic behavior and bounded errors, even though some
formalisms might have difficulties in distinguishing betwee3n them.

The best way to think of bounded errors is as erroneoues situations in which
there
are some bounds on what can happen as a result of the error. It is wrong
to think of bounded errors as simply specifying non-deterministic execution.

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

[Franco Mazzanti]

Robert Dewar said:
 "Well anyone can use language any way they like, but in the normal English
 meaning of the word unpredictable (which is the proper one to be using,
 since unpredictable is not  technical term), of course bounded errors
 result in unpredictable program execution, in that you cannot predict
 what will happen. "

Probably a gave a too technical meaning to the term "predictable".
In effect, the RM index doen not contain the entry "unpredictable"
or "predictable" or "not predictable". And this is a sign that the
use of the term was not meant to be strictly "technical".

However, it is also true that the Reference Manual associates
the (normal English) term "unpredictable" (or "not predictable")
only to erroneous executions, and not to bounded errors.
Therefore encouraging, expecially to those people whose native language
is not English, the impression that it is correct to associate the
(normal English) term "unpredictable" only to erroneous executions.

Even more, in 13.9.1(11) it is explicitly said that the use of an invalid
value (which is probably the "least predictable" case of bounded errors)
does not lead to "unpredictable" execution.

Quoting RM 13.9.1(11):
    "If the representation of the object does not represent a value of
    the object's type, the semantics of operations on such
    representations is implementation-defined, but does not by itself
    lead to erroneous or unpredictable execution, or to other objects
    becoming abnormal."

I agree with Robert that "anyone can use language any way they like"
(also the authors of the Reference Manual), but I was not too wrong when
I said that the RM did not consider bounded errors as cases of true
"unpredictability" (whether or not this is correct from the point
of view of normal English usage of the term "predictable").

By the way, I completely agree that bounded-errors are not like
non-deterministic behaviour (just because they ARE errors).

Franco Mazzanti

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

[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

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

[Franco Mazzanti]

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

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

[Robert Dewar]

Bob said

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

Absolutely, anything else makes no sense. Note that in all cases leaving
something to be implementation dependent expects a reasonable choice. 
There is no particular reason to try to pin this down in the RM. For
example, I would regard it as a waste of time to worry about whether the
above rule is in the RM or not.

From a practical point of view, people expect that an implementation
dependent choice be reasonable.

For example, if in my Annex M I write:

  The value used for Count'Max depends on the stars at the time of the
  compilation, if aries is in the ascendent then.... (500 more lines of
  gobbledygook written by Nancy Reagan's astrologer).

then I am technically compliant, but this is no more reasonable or useful
than reutrning an abnormal result. Either compiler is obviously a piece
of junk. The RM cannot preevent a determined implementor from producing
a completely useless compiler!

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

[Robert Dewar]

Franco quoted the reference manual

"   11  If the representation of the object does not represent a value of
       the object's type, the semantics of operations on such
       representations is implementation-defined, but does not by itself
       lead to erroneous or unpredictable execution, or to other objects
       becoming abnormal."

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 :-)

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

[Franco Mazzanti]

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