1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>AARM95 - Completion and Finalization</TITLE>
<META NAME="Author" CONTENT="JTC1/SC22/WG9/ARG, by Randall Brukardt, ARG Editor">
<META NAME="GENERATOR" CONTENT="Arm_Form.Exe, Ada Reference Manual generator">
<STYLE type="text/css">
DIV.paranum {position: absolute; font-family: Arial, Helvetica, sans-serif; left: 0.5 em; top: auto}
TT {font-family: "Courier New", monospace}
DT {display: compact}
DIV.Normal {font-family: "Times New Roman", Times, serif; margin-bottom: 0.6em}
DIV.Wide {font-family: "Times New Roman", Times, serif; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Annotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.WideAnnotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Index {font-family: "Times New Roman", Times, serif}
DIV.SyntaxSummary {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Notes {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.NotesHeader {font-family: "Times New Roman", Times, serif; margin-left: 2.0em}
DIV.SyntaxIndented {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Indented {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-bottom: 0.6em}
DIV.CodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.SmallIndented {font-family: "Times New Roman", Times, serif; margin-left: 10.0em; margin-bottom: 0.6em}
DIV.SmallCodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.Examples {font-family: "Courier New", monospace; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.SmallExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 7.5em; margin-bottom: 0.6em}
DIV.IndentedExamples {font-family: "Courier New", monospace; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.SmallIndentedExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 15.0em; margin-bottom: 0.6em}
UL.Bulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.IndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SyntaxIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.Hanging {font-family: "Times New Roman", Times, serif; margin-top: 0em; margin-bottom: 0.6em}
DD.Hanging {margin-left: 6.0em}
DL.IndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.IndentedHanging {margin-left: 2.0em}
DL.HangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.HangingInBulleted {margin-left: 4.0em}
DL.SmallHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallHanging {margin-left: 7.5em}
DL.SmallIndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallIndentedHanging {margin-left: 2.0em}
DL.SmallHangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallHangingInBulleted {margin-left: 5.0em}
DL.Enumerated {font-family: "Times New Roman", Times, serif; margin-right: 0.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.Enumerated {margin-left: 2.0em}
DL.SmallEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallEnumerated {margin-left: 2.5em}
DL.NestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.SmallNestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
</STYLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFF0" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-7-6.html">Previous</A> <A HREF="AA-8.html">Next</A></P>
<HR>
<H1> 7.6.1 Completion and Finalization</H1>
<DIV Class="Paranum"><FONT SIZE=-2>1</FONT></DIV>
<DIV Class="Normal"> [This subclause defines <I>completion</I> and
<I>leaving</I> of the execution of constructs and entities. A <I>master</I>
is the execution of a construct that includes finalization of local objects
after it is complete (and after waiting for any local tasks -- see <A HREF="AA-9-3.html">9.3</A>),
but before leaving. Other constructs and entities are left immediately
upon completion. <A NAME="I3294"></A><A NAME="I3295"></A>]</DIV>
<H4 ALIGN=CENTER>Dynamic Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>2</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3296"></A><A NAME="I3297"></A>The execution
of a construct or entity is <I>complete</I> when the end of that execution
has been reached, or when a transfer of control (see <A HREF="AA-5-1.html">5.1</A>)
causes it to be abandoned. <A NAME="I3298"></A><A NAME="I3299"></A><A NAME="I3300"></A><A NAME="I3301"></A>Completion
due to reaching the end of execution, or due to the transfer of control
of an <FONT FACE="Arial, Helvetica">exit_</FONT>, <FONT FACE="Arial, Helvetica">return_</FONT>,
<FONT FACE="Arial, Helvetica">goto_</FONT>, or <FONT FACE="Arial, Helvetica">requeue_statement</FONT>
or of the selection of a <FONT FACE="Arial, Helvetica">terminate_alternative</FONT>
is <I>normal completion</I>. Completion is <I>abnormal</I> otherwise
[-- when control is transferred out of a construct due to abort or the
raising of an exception]. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Don't confuse
the run-time concept of completion with the compile-time concept of completion
defined in <A HREF="AA-3-11-1.html">3.11.1</A>. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3302"></A><A NAME="I3303"></A>After
execution of a construct or entity is complete, it is <I>left</I>, meaning
that execution continues with the next action, as defined for the execution
that is taking place. <A NAME="I3304"></A>Leaving an execution happens
immediately after its completion, except in the case of a <I>master</I>:
the execution of a <FONT FACE="Arial, Helvetica">task_body</FONT>, a
<FONT FACE="Arial, Helvetica">block_statement</FONT>, a <FONT FACE="Arial, Helvetica">subprogram_body</FONT>,
an <FONT FACE="Arial, Helvetica">entry_body</FONT>, or an <FONT FACE="Arial, Helvetica">accept_statement</FONT>.
A master is finalized after it is complete, and before it is left.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>Note that although
an <FONT FACE="Arial, Helvetica">accept_statement</FONT> has no <FONT FACE="Arial, Helvetica">declarative_part</FONT>,
it can call functions and evaluate <FONT FACE="Arial, Helvetica">aggregate</FONT>s,
possibly causing anonymous controlled objects to be created, and we don't
want those objects to escape outside the rendezvous. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3305"></A>For the <I>finalization</I>
of a master, dependent tasks are first awaited, as explained in <A HREF="AA-9-3.html">9.3</A>.
Then each object whose accessibility level is the same as that of the
master is finalized if the object was successfully initialized and still
exists. [These actions are performed whether the master is left by reaching
the last statement or via a transfer of control.] When a transfer of
control causes completion of an execution, each included master is finalized
in order, from innermost outward. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>As explained
in <A HREF="AA-3-10-2.html">3.10.2</A>, the set of objects with the same
accessibility level as that of the master includes objects declared immediately
within the master, objects declared in nested packages, objects created
by <FONT FACE="Arial, Helvetica">allocator</FONT>s (if the ultimate ancestor
access type is declared in one of those places) and subcomponents of
all of these things. If an object was already finalized by Unchecked_Deallocation,
then it is not finalized again when the master is left.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that any object whose accessibility
level is deeper than that of the master would no longer exist; those
objects would have been finalized by some inner master. Thus, after leaving
a master, the only objects yet to be finalized are those whose accessibility
level is less deep than that of the master.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B>Subcomponents
of objects due to be finalized are not finalized by the finalization
of the master; they are finalized by the finalization of the containing
object. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>We need to finalize
subcomponents of objects even if the containing object is not going to
get finalized because it was not fully initialized. But if the containing
object is finalized, we don't want to require repeated finalization of
the subcomponents, as might normally be implied by the recursion in finalization
of a master and the recursion in finalization of an object. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B>Formally,
completion and leaving refer to executions of constructs or entities.
However, the standard sometimes (informally) refers to the constructs
or entities whose executions are being completed. Thus, for example,
``the <FONT FACE="Arial, Helvetica">subprogram_call</FONT> or task is
complete'' really means ``<I>the execution of</I> the <FONT FACE="Arial, Helvetica">subprogram_call</FONT>
or task is complete.'' </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> <A NAME="I3306"></A>For
the <I>finalization</I> of an object: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If the object is of an elementary type, finalization has
no effect;</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>7</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If the object is of a controlled type, the Finalize procedure
is called;</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>8</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If the object is of a protected type, the actions defined
in <A HREF="AA-9-4.html">9.4</A> are performed;</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>9</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If the object is of a composite type, then after performing
the above actions, if any, every component of the object is finalized
in an arbitrary order, except as follows: if the object has a component
with an access discriminant constrained by a per-object expression, this
component is finalized before any components that do not have such discriminants;
for an object with several components with such a discriminant, they
are finalized in the reverse of the order of their <FONT FACE="Arial, Helvetica">component_declaration</FONT>s.
</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>9.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>This allows the
finalization of a component with an access discriminant to refer to other
components of the enclosing object prior to their being finalized. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3307"></A>Immediately before an instance
of Unchecked_Deallocation reclaims the storage of an object, the object
is finalized. [If an instance of Unchecked_Deallocation is never applied
to an object created by an <FONT FACE="Arial, Helvetica">allocator</FONT>,
the object will still exist when the corresponding master completes,
and it will be finalized then.]</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11</FONT></DIV>
<DIV Class="Normal"> The order in which the finalization of a master
performs finalization of objects is as follows: Objects created by declarations
in the master are finalized in the reverse order of their creation. For
objects that were created by <FONT FACE="Arial, Helvetica">allocator</FONT>s
for an access type whose ultimate ancestor is declared in the master,
this rule is applied as though each such object that still exists had
been created in an arbitrary order at the first freezing point (see <A HREF="AA-13-14.html">13.14</A>)
of the ultimate ancestor type. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>Note that we talk
about the type of the <FONT FACE="Arial, Helvetica">allocator</FONT>
here. There may be access values of a (general) access type pointing
at objects created by <FONT FACE="Arial, Helvetica">allocator</FONT>s
for some other type; these are not finalized at this point.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The freezing point of the ultimate
ancestor access type is chosen because before that point, pool elements
cannot be created, and after that point, access values designating (parts
of) the pool elements can be created. This is also the point after which
the pool object cannot have been declared. We don't want to finalize
the pool elements until after anything finalizing objects that contain
access values designating them. Nor do we want to finalize pool elements
after finalizing the pool object itself. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Finalization
of allocated objects is done according to the (ultimate ancestor) <FONT FACE="Arial, Helvetica">allocator</FONT>
type, not according to the storage pool in which they are allocated.
Pool finalization might reclaim storage (see <A HREF="AA-13-11.html">13.11</A>,
``<A HREF="AA-13-11.html">Storage Management</A>''), but has nothing
(directly) to do with finalization of the pool elements.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that finalization is done
only for objects that still exist; if an instance of Unchecked_Deallocation
has already gotten rid of a given pool element, that pool element will
not be finalized when the master is left.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that a deferred constant
declaration does not create the constant; the full constant declaration
creates it. Therefore, the order of finalization depends on where the
full constant declaration occurs, not the deferred constant declaration.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An imported object is not created
by its declaration. It is neither initialized nor finalized. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>An
implementation has to ensure that the storage for an object is not reclaimed
when references to the object are still possible (unless, of course,
the user explicitly requests reclamation via an instance of Unchecked_Deallocation).
This implies, in general, that objects cannot be deallocated one by one
as they are finalized; a subsequent finalization might reference an object
that has been finalized, and that object had better be in its (well-defined)
finalized state. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3308"></A>The target of an assignment
statement is finalized before copying in the new value, as explained
in <A HREF="AA-7-6.html">7.6</A>.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13/1</FONT></DIV>
<DIV Class="Normal"> {<I><A HREF="defect1.html#8652/0021">8652/0021</A></I>}
<U>If the <FONT FACE="Arial, Helvetica">object_name</FONT> in an <FONT FACE="Arial, Helvetica">object_renaming_declaration</FONT>,
or the actual parameter for a generic formal <B>in out</B> parameter
in a <FONT FACE="Arial, Helvetica">generic_instantiation</FONT>, denotes
any part of an anonymous object created by a function call, the anonymous
object is not finalized until after it is no longer accessible via any
name. Otherwise, an</U><S>The</S> anonymous object<S>s</S> created by
<U>a </U>function <U>call or</U><S>calls and</S> by <U>an </U><FONT FACE="Arial, Helvetica">aggregate</FONT><U>
is</U><S>s are</S> finalized no later than the end of the innermost enclosing
<FONT FACE="Arial, Helvetica">declarative_item</FONT> or <FONT FACE="Arial, Helvetica">statement</FONT>;
if that is a <FONT FACE="Arial, Helvetica">compound_statement</FONT>,
<U>the object is</U><S>they are</S> finalized before starting the execution
of any <FONT FACE="Arial, Helvetica">statement</FONT> within the <FONT FACE="Arial, Helvetica">compound_statement</FONT>.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.a</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>To
be honest: </B>This is not to be construed as permission to call Finalize
asynchronously with respect to normal user code. For example, </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.b</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>declare</B><BR>
X : Some_Controlled_Type := F(G(...));<BR>
--<I> The anonymous objects created for F and G are finalized</I><BR>
--<I> no later than this point.</I><BR>
Y : ...<BR>
<B>begin</B><BR>
...<BR>
<B>end</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The anonymous object for G should
not be finalized at some random point in the middle of the body of F,
because F might manipulate the same data structures as the Finalize operation,
resulting in erroneous access to shared variables. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>It might be quite
inconvenient for the implementation to defer finalization of the anonymous
object for G until after copying the value of F into X, especially if
the size of the result is not known at the call site. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.1/1</FONT></DIV>
<DIV Class="Normal"> {<I><A HREF="defect1.html#8652/0023">8652/0023</A></I>}
<U>If a transfer of control or raising of an exception occurs prior to
performing a finalization of an anonymous object, the anonymous object
is finalized as part of the finalizations due to be performed for the
object's innermost enclosing master.</U></DIV>
<H4 ALIGN=CENTER>Bounded (Run-Time) Errors</H4>
<DIV Class="Paranum"><FONT SIZE=-2>14/1</FONT></DIV>
<DIV Class="Normal"> {<I><A HREF="defect1.html#8652/0023">8652/0023</A></I>}
<A NAME="I3309"></A>It is a bounded error for a call on Finalize or Adjust
<U>that occurs as part of object finalization or assignment </U>to propagate
an exception. The possible consequences depend on what action invoked
the Finalize or Adjust operation: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14.a</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>It is not a bounded error for Initialize to propagate an exception.
If Initialize propagates an exception, then no further calls on Initialize
are performed, and those components that have already been initialized
(either explicitly or by default) are finalized in the usual way.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14.a.1/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>{<I><A HREF="defect1.html#8652/0023">8652/0023</A></I>}
<U>It also is not a bounded error for an explicit call to Finalize or
Adjust to propagate an exception. We do not want implementations to have
to treat explicit calls to these routines specially.</U> </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>15</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC><A NAME="I3310"></A>For a Finalize invoked as part of an
<FONT FACE="Arial, Helvetica">assignment_statement</FONT>, Program_Error
is raised at that point.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>16/1</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>{<I><A HREF="defect1.html#8652/0024">8652/0024</A></I>}
<U>For an Adjust invoked as part of the initialization of a controlled
object, other adjustments due to be performed might or might not be performed,
and then Program_Error is raised. During its propagation, finalization
might or might not be applied to objects whose Adjust failed.</U> <A NAME="I3311"></A>For
an Adjust invoked as part of an assignment <U>statement</U><S>operation</S>,
any other adjustments due to be performed are performed, and then Program_Error
is raised. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>16.a.1/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>{<I><A HREF="defect1.html#8652/0024">8652/0024</A></I>}
<U>In the case of assignments that are part of initialization, there
is no need to complete all adjustments if one propagates an exception,
as the object will immediately be finalized. So long as a subcomponent
is not going to be finalized, it need not be adjusted, even if it is
initialized as part of an enclosing composite assignment operation for
which some adjustments are performed. However, there is no harm in an
implementation making additional Adjust calls (as long as any additional
components that are adjusted are also finalized), so we allow the implementation
flexibility here. On the other hand, for an assignment statement, it
is important that all adjustments be performed, even if one fails, because
all controlled subcomponents are going to be finalized.</U> </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.a.2/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>{<I><A HREF="defect1.html#8652/0024">8652/0024</A></I>}
<U>Even if an Adjust invoked as part of the initialization of a controlled
object propagates an exception, objects whose initialization (including
any Adjust or Initialize calls) successfully completed will be finalized.
The permission above only applies to objects whose Adjust failed. Objects
for which Adjust was never even invoked must not be finalized.</U> </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC><A NAME="I3312"></A>For a Finalize invoked as part of a
call on an instance of Unchecked_Deallocation, any other finalizations
due to be performed are performed, and then Program_Error is raised.
</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>17.a.1/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>{<I><A HREF="defect2.html#8652/0104">8652/0104</A></I>}
<U>The standard does not specify if storage is recovered in this case.
If storage is not recovered (and the object continues to exist), Finalize
may be called on the object again (when the <FONT FACE="Arial, Helvetica">allocator</FONT>'s
master is finalized).</U> </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.1/1</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>{<I><A HREF="defect1.html#8652/0023">8652/0023</A></I>}
<U><A NAME="I3313"></A>For a Finalize invoked as part of the finalization
of the anonymous object created by a function call or <FONT FACE="Arial, Helvetica">aggregate</FONT>,
any other finalizations due to be performed are performed, and then Program_Error
is raised.</U></LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>17.2/1</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>{<I><A HREF="defect1.html#8652/0023">8652/0023</A></I>}
<U><A NAME="I3314"></A>For a Finalize invoked due to reaching the end
of the execution of a master, any other finalizations associated with
the master are performed, and Program_Error is raised immediately after
leaving the master.</U></LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>18</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC><A NAME="I3315"></A>For a Finalize invoked by the transfer
of control of an <FONT FACE="Arial, Helvetica">exit_</FONT>, <FONT FACE="Arial, Helvetica">return_</FONT>,
<FONT FACE="Arial, Helvetica">goto_</FONT>, or <FONT FACE="Arial, Helvetica">requeue_statement</FONT>,
Program_Error is raised no earlier than after the finalization of the
master being finalized when the exception occurred, and no later than
the point where normal execution would have continued. Any other finalizations
due to be performed up to that point are performed before raising Program_Error.
</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>18.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For example,
upon leaving a <FONT FACE="Arial, Helvetica">block_statement</FONT> due
to a <FONT FACE="Arial, Helvetica">goto_statement</FONT>, the Program_Error
would be raised at the point of the target statement denoted by the label,
or else in some more dynamically nested place, but not so nested as to
allow an <FONT FACE="Arial, Helvetica">exception_handler</FONT> that
has visibility upon the finalized object to handle it. For example, </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.b</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>procedure</B> Main <B>is</B><BR>
<B>begin</B><BR>
<<The_Label>><BR>
Outer_Block_Statement : <B>declare</B><BR>
X : Some_Controlled_Type;<BR>
<B>begin</B><BR>
Inner_Block_Statement : <B>declare</B><BR>
Y : Some_Controlled_Type;<BR>
Z : Some_Controlled_Type;<BR>
<B>begin</B><BR>
<B>goto</B> The_Label;<BR>
<B>exception</B><BR>
<B>when</B> Program_Error => ... --<I> Handler number 1.</I><BR>
<B>end</B>;<BR>
<B>exception</B><BR>
<B>when</B> Program_Error => ... --<I> Handler number 2.</I><BR>
<B>end</B>;<BR>
<B>exception</B><BR>
<B>when</B> Program_Error => ... --<I> Handler number 3.</I><BR>
<B>end</B> Main;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The <FONT FACE="Arial, Helvetica">goto_statement</FONT>
will first cause Finalize(Y) to be called. Suppose that Finalize(Y) propagates
an exception. Program_Error will be raised after leaving Inner_Block_Statement,
but before leaving Main. Thus, handler number 1 cannot handle this Program_Error;
it will be handled either by handler number 2 or handler number 3. If
it is handled by handler number 2, then Finalize(Z) will be done before
executing the handler. If it is handled by handler number 3, then Finalize(Z)
and Finalize(X) will both be done before executing the handler. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>For a Finalize invoked by a transfer of control that is
due to raising an exception, any other finalizations due to be performed
for the same master are performed; Program_Error is raised immediately
after leaving the master. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>19.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>If, in the
above example, the <FONT FACE="Arial, Helvetica">goto_statement</FONT>
were replaced by a <FONT FACE="Arial, Helvetica">raise_statement</FONT>,
then the Program_Error would be handled by handler number 2, and Finalize(Z)
would be done before executing the handler. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>We considered treating
this case in the same way as the others, but that would render certain
<FONT FACE="Arial, Helvetica">exception_handler</FONT>s useless. For
example, suppose the only <FONT FACE="Arial, Helvetica">exception_handler</FONT>
is one for <B>others</B> in the main subprogram. If some deeply nested
call raises an exception, causing some Finalize operation to be called,
which then raises an exception, then normal execution ``would have continued''
at the beginning of the <FONT FACE="Arial, Helvetica">exception_handler</FONT>.
Raising Program_Error at that point would cause that handler's code to
be skipped. One would need two nested <FONT FACE="Arial, Helvetica">exception_handler</FONT>s
to be sure of catching such cases!</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>On the other hand, the <FONT FACE="Arial, Helvetica">exception_handler</FONT>
for a given master should not be allowed to handle exceptions raised
during finalization of that master. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>For a Finalize invoked by a transfer of control due to
an abort or selection of a terminate alternative, the exception is ignored;
any other finalizations due to be performed are performed. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>20.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>This case
includes an asynchronous transfer of control. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B><A NAME="I3316"></A>This
violates the general principle that it is always possible for a bounded
error to raise Program_Error (see <A HREF="AA-1-1-5.html">1.1.5</A>,
``<A HREF="AA-1-1-5.html">Classification of Errors</A>''). </FONT></DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>18 The rules of Section 10
imply that immediately prior to partition termination, Finalize operations
are applied to library-level controlled objects (including those created
by <FONT FACE="Arial, Helvetica">allocator</FONT>s of library-level access
types, except those already finalized). This occurs after waiting for
library-level tasks to terminate. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>We considered
defining a pragma that would apply to a controlled type that would suppress
Finalize operations for library-level objects of the type upon partition
termination. This would be useful for types whose finalization actions
consist of simply reclaiming global heap storage, when this is already
provided automatically by the environment upon program termination. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>22</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>19 A constant is only constant
between its initialization and finalization. Both initialization and
finalization are allowed to change the value of a constant.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>23</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>20 Abort is deferred during
certain operations related to controlled types, as explained in <A HREF="AA-9-8.html">9.8</A>.
Those rules prevent an abort from causing a controlled object to be left
in an ill-defined state.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>21 The Finalize procedure
is called upon finalization of a controlled object, even if Finalize
was called earlier, either explicitly or as part of an assignment; hence,
if a controlled type is visibly controlled (implying that its Finalize
primitive is directly callable), or is nonlimited (implying that assignment
is allowed), its Finalize procedure should be designed to have no ill
effect if it is applied a second time to the same object. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Or equivalently,
a Finalize procedure should be ``idempotent''; applying it twice to the
same object should be equivalent to applying it once. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>A user-written
Finalize procedure should be idempotent since it can be called explicitly
by a client (at least if the type is "visibly" controlled).
Also, Finalize is used implicitly as part of the <FONT FACE="Arial, Helvetica">assignment_statement</FONT>
if the type is nonlimited, and an abort is permitted to disrupt an <FONT FACE="Arial, Helvetica">assignment_statement</FONT>
between finalizing the left-hand side and assigning the new value to
it (an abort is not permitted to disrupt an assignment operation between
copying in the new value and adjusting it). </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Either Initialize
or Adjust, but not both, is applied to (almost) every controlled object
when it is created: Initialize is done when no initial value is assigned
to the object, whereas Adjust is done as part of assigning the initial
value. The one exception is the anonymous object created by an <FONT FACE="Arial, Helvetica">aggregate</FONT>;
Initialize is not applied to the <FONT FACE="Arial, Helvetica">aggregate</FONT>
as a whole, nor is the value of the <FONT FACE="Arial, Helvetica">aggregate</FONT>
adjusted.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.d</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><A NAME="I3317"></A>All
of the following use the assignment operation, and thus perform value
adjustment: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.e</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>the <FONT FACE="Arial, Helvetica">assignment_statement</FONT>
(see <A HREF="AA-5-2.html">5.2</A>);</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.f</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>explicit initialization of a stand-alone object (see <A HREF="AA-3-3-1.html">3.3.1</A>)
or of a pool element (see <A HREF="AA-4-8.html">4.8</A>);</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.g</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>default initialization of a component of a stand-alone
object or pool element (in this case, the value of each component is
assigned, and therefore adjusted, but the value of the object as a whole
is not adjusted);</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.h</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>function return, when the result type is not a return-by-reference
type (see <A HREF="AA-6-5.html">6.5</A>); (adjustment of the result happens
before finalization of the function; values of return-by-reference types
are not adjusted);</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.i</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>predefined operators (although the only one that matters
is concatenation; see <A HREF="AA-4-5-3.html">4.5.3</A>);</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.j</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>generic formal objects of mode <B>in</B> (see <A HREF="AA-12-4.html">12.4</A>);
these are defined in terms of <FONT FACE="Arial, Helvetica">constant_declaration</FONT>s;
and</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.k</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC><FONT FACE="Arial, Helvetica">aggregate</FONT>s (see <A HREF="AA-4-3.html">4.3</A>)
(in this case, the value of each component, and the parent part, for
an <FONT FACE="Arial, Helvetica">extension_aggregate</FONT>, is assigned,
and therefore adjusted, but the value of the <FONT FACE="Arial, Helvetica">aggregate</FONT>
as a whole is not adjusted; neither is Initialize called); </LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.l</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>The
following also use the assignment operation, but adjustment never does
anything interesting in these cases: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.m</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>By-copy parameter passing uses the assignment operation
(see <A HREF="AA-6-4-1.html">6.4.1</A>), but controlled objects are always
passed by reference, so the assignment operation never does anything
interesting in this case. If we were to allow by-copy parameter passing
for controlled objects, we would need to make sure that the actual is
finalized before doing the copy back for [<B>in</B>] <B>out</B> parameters.
The finalization of the parameter itself needs to happen after the copy
back (if any), similar to the finalization of an anonymous function return
object or <FONT FACE="Arial, Helvetica">aggregate</FONT> object.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.n</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC><B>For</B> loops use the assignment operation (see <A HREF="AA-5-5.html">5.5</A>),
but since the type of the loop parameter is never controlled, nothing
interesting happens there, either. </LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>24.o</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Because Controlled and Limited_Controlled
are library-level tagged types, all controlled types will be library-level
types, because of the accessibility rules (see <A HREF="AA-3-10-2.html">3.10.2</A>
and <A HREF="AA-3-9-1.html">3.9.1</A>). 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.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.p</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Finalization of the parts of a
protected object are not done as protected actions. It is possible (in
pathological cases) to create tasks during finalization that access these
parts in parallel with the finalization itself. This is an erroneous
use of shared variables. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.q</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>One
implementation technique for finalization is to chain the controlled
objects together on a per-task list. When leaving a master, the list
can be walked up to a marked place. The links needed to implement the
list can be declared (privately) in types Controlled and Limited_Controlled,
so they will be inherited by all controlled types.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.r</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Another implementation technique,
which we refer to as the ``PC-map'' approach essentially implies inserting
exception handlers at various places, and finalizing objects based on
where the exception was raised.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.s</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I3318"></A><A NAME="I3319"></A>The
PC-map approach is for the compiler/linker to create a map of code addresses;
when an exception is raised, or abort occurs, the map can be consulted
to see where the task was executing, and what finalization needs to be
performed. This approach was given in the Ada 83 Rationale as a possible
implementation strategy for exception handling -- the map is consulted
to determine which exception handler applies.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.t</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If the PC-map approach is used,
the implementation must take care in the case of arrays. The generated
code will generally contain a loop to initialize an array. If an exception
is raised part way through the array, the components that have been initialized
must be finalized, and the others must not be finalized.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.u</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>It is our intention that both
of these implementation methods should be possible. </FONT></DIV>
<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>24.v</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Finalization depends on the concepts
of completion and leaving, and on the concept of a master. Therefore,
we have moved the definitions of these concepts here, from where they
used to be in Section 9. These concepts also needed to be generalized
somewhat. Task waiting is closely related to user-defined finalization;
the rules here refer to the task-waiting rules of Section 9. </FONT></DIV>
<HR>
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-7-6.html">Previous</A> <A HREF="AA-8.html">Next</A> <A HREF="AA-TTL.html">Legal</A></P>
</BODY>
</HTML>
|
