File: defect1.html

package info (click to toggle)
ada-reference-manual 20021112web-3
links: PTS
area: main
in suites: etch, etch-m68k, lenny, sarge
size: 18,652 kB
ctags: 8,921
sloc: makefile: 52; sh: 20
file content (10538 lines) | stat: -rw-r--r-- 508,544 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
    <TITLE>Ada 95 Defect Reports - Part 1</TITLE>
    <META NAME="Author" CONTENT="JTC 1/SC 22/WG 9/ARG, by Randall Brukardt, ARG Editor">
    <META NAME="GENERATOR" CONTENT="AICorr.Exe, Corrigedum generator">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFF0" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">

<H1 ALIGN=CENTER><FONT FACE="Arial, Helvetica"><B>Programming languages -- Ada<BR>
DEFECT REPORTS</B><BR>
Part 1<BR>
<FONT SIZE=+2>For ISO/IEC 8652:1995</FONT></FONT></H1>

<P><BR><BR></P>

<P ALIGN=CENTER><FONT FACE="Arial, Helvetica"><FONT SIZE=+2>September 2000</FONT></FONT></P>
<P><BR><BR></P>
<P>This document was
prepared by AXE Consulting under contract from The MITRE Corporation.</P>
<P></P>

<P>&#169 2000, The MITRE Corporation. All Rights Reserved.</P>
<P></P>

<P>This document may be copied, in whole or in part, in any form or by any
means, as is, or with alterations, provided that (1) alterations are
clearly marked as alterations and (2) this copyright notice is included
unmodified in any copy. Any other use or distribution of this document
is prohibited without the prior express permission of MITRE.</P>
<P>You use this document on the condition that you indemnify and hold
harmless MITRE, its Board of Trustees, officers, agents, and employees,
from any and all liability or damages to yourself or your hardware or
software, or third parties, including attorneys' fees, court costs, and
other related costs and expenses, arising out of your use of this
document irrespective of the cause of said liability.</P>
<P></P>

<P>MITRE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL
MITRE BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF MITRE HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.</P>


<H2><FONT FACE="Arial, Helvetica">Introduction</FONT></H2>

<P>This document contains defect reports on the Ada 95 standard 
[ISO/IEC 8652:1995], and responses formulated by the Ada Rapporteur Group 
(ARG) of ISO/IEC JTC&nbsp;1/SC&nbsp;22/WG&nbsp;9, the Ada working group. The ARG is the language 
maintenance subgroup of WG&nbsp;9, meaning that it is responsible for determining 
the corrections to the standard.</P>

<P>Defect Reports usually come from comments submitted by the public to the ARG. 
These comments are distilled into a question, given in the <B>Question</B> section 
of the Defect Report response.</P>

<P>In order to formulate the response to the Defect Report, the question is 
carefully considered and often discussed at length by the ARG. The results 
are recorded in the <B>Discussion</B> section of the response. The answer to the 
question arrived at after the discussions is summarized in the <B>Summary of 
Response</B> section. A more detailed answer to the question can be found in the 
<B>Response</B> section. Sometimes, the issue is so obvious that there is no <B>Response</B> 
or <B>Discussion</B> section. If the result of the discussion finds that some change 
to the standard would be required to arrive at an answer to the question, a 
<B>Corrigendum Wording</B> section includes the specific wording change to standard. 
These <B>Corrigendum Wording</B> sections are gathered together in a Technical 
Corrigendum document.</P>

<P>A Defect Report and Response is the final step of a lengthy process of formulation, discussion, and approval. 
The working documents of the ARG (called <I>Ada Issues</I>) contain additional information about the 
issue and its resolution. Ada Issues may include sections for testing information (<B>ACATS test</B>), 
informal wording changes (<B>Wording</B>), and an appendix including E-Mail comments 
on this issue (<B>Appendix</B>). These sections are not included in the Defect Reports found 
in this document. This information is available in the Ada Issues documents, which can be accessed 
on the web at www.ada-auth.org/~acats/arg.</P>

<P>The Defect Reports and Responses contain many references of the form ss.cc(pp) 
or ss.cc.aa(pp). These refer to particular paragraphs in the standard, with 
the notation referencing the (sub)clause number in the Ada 95 standard 
(ss.cc.aa), followed by a parenthesized paragraph number (pp). Paragraphs are 
numbered by counting from the top of the (sub)clause, ignoring headings.</P>

<P>The Defect Reports and Responses contain references to the Annotated Ada
Reference Manual (AARM). This document contains all of the text in the Ada 95
standard along with various annotations. It was prepared by the
Ada 95 design team, and is intended primarily for compiler writers, test
writers, and the ARG. The annotations include rationale for some rules. The AARM
is often used by the ARG to determine the intent of the language designers.</P>

<P>The Defect Reports and Responses may contain references to Ada 83.
Ada 83 is the common name for the previous version of the Ada standard,
ISO/IEC 8652:1987. Similarly, AI83 refers to interpretations of
that standard.</P>

<P>This document contains all of the Defect Reports used to prepare Ada Technical Corrigendum 1. 
Issues which did not result in wording changes to the standard are available in the 
companion document, <A HREF="defect2.html">Defect Reports Part 2</A>. 
Resolutions of newer issues can be found on the web site mentioned previously.</P>

<P>This document is designed to be viewed with the default font as some Roman font,
similar to the Ada 95 standard. This may require some adjustments to your browser.</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0001"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0001 -  The AE characters are allowed in identifiers</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00124<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 1.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>2.1(8-9) say:
</P>
<P><UL>upper_case_identifier_letter
</UL></P>
<P><UL><UL>Any character of Row 00 of ISO 10646 BMP whose name begins
``Latin Capital Letter''.
</UL></UL></P>
<P><UL>lower_case_identifier_letter
</UL></P>
<P><UL><UL>Any character of Row 00 of ISO 10646 BMP whose name begins
``Latin Small Letter''.
</UL></UL></P>
<P>The letters allowed in identifiers are then restricted to
lower_case_identifier_letters and upper_case_identifier_letters.
</P>
<P>The version of 10646-1:1993 referred to in 1.2(8) names codes C6
and E6 as &quot;Latin Capital Ligature AE&quot; and &quot;Latin Small Ligature AE&quot;.
</P>
<P>This seems to imply that these characters are not allowed in identifiers.
Are these characters allowed in identifiers? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The characters LATIN CAPITAL LETTER AE and LATIN SMALL LETTER AE
are allowed in identifiers.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  1.2(8):   </FONT></B></P>
<UL><P>ISO/IEC 10646-1:1993, <I>Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual
Plane</I>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>ISO/IEC 10646-1:1993, <I>Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual
Plane</I>, supplemented by Technical Corrigendum 1:1996.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Technical Corrigendum 1 of 10646 names these characters LATIN CAPITAL
LETTER AE and LATIN SMALL LETTER AE.  The intent was that these letters
be allowed in identifiers.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0002"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0002 -  Elaboration of subtype_indications with per-object constraints</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00171<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.3.1;  3.6;  3.8;  4.8;  9.5.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>When does the elaboration of a subtype indication with a per-object
constraint occur?  What are the actions of such an elaboration?
</P>
<P>When a component has a subtype_indication with a per-object constraint
and an object of the type containing the component is declared, the
subtype_indication containing the per-object constraint is apparently
never elaborated.
</P>
<P>3.8(18) explains that subtype_indications with per-object constraints
are not elaborated, but that any expressions that are not part of a
per-object expression are evaluated.  However, what to do with the
results of those evaluations never seems to be explained.
</P>
<P>3.3.1(15-20) describes the process of elaborating an object_declaration.
In step 3, per-object expressions are evaluated, but there is no mention
of elaborating anything, although later paragraph 20 does seem to imply
that some sort of elaborations were supposed to have taken place in step 3.
</P>
<P>The elaboration of per-object constraints is mentioned in (at least)
the following other places where objects are created:
</P>
<P><UL>4.3.1(19)  creating record aggregates
</UL></P>
<P><UL>4.8(10)    creating heap objects via uninitialized allocators
</UL></P>
<P><UL>9.4(14)    creating a protected object (This one is supposed to be redundant
with 3.3.1, but in fact the two appear to be inconsistent.)
</UL></P>
<P>According to a strict reading, elaborating the per-object constraint would
appear to involve reevaluating the non-per-object expressions (since there
doesn't seem to be any separate definition of what happens when a per-object
constraint is elaborated), but not include any subtype compatibility checks
that would normally occur as part of subtype elaboration (since elaboration
of the subtype_indication containing the constraint isn't mentioned in these
paragraphs).  What are the intended semantics?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The elaboration of a subtype indication with a per-object constraint
occurs when an object of the enclosing type is created. This elaboration
consists of the evaluation of each per-object expression of the constraint,
followed by the usual actions associated with such elaboration, but using
the values for any expressions that are not part of a per-object expression
that were determined earlier when the type definition was elaborated.
</P>
<P>For evaluating a named association applying to multiple components in a
per-object discriminant constraint, if the expression of the association
is not part of a per-object expression, then it must be evaluated once
for each associated component.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.3.1(18):   </FONT></B></P>
<P><UL><DL>
<DT>   3.<DD>The object is created, and, if there is not an initialization
expression, any per-object expressions (see 3.8) are evaluated
and any implicit initial values for the object or for its
subcomponents are obtained as determined by the nominal subtype.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>   3.<DD>The object is created, and, if there is not an initialization
expression, any per-object constraints (see 3.8) are elaborated
and any implicit initial values for the object or for its
subcomponents are obtained as determined by the nominal subtype.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.6(22):   </FONT></B></P>
<UL><P>The elaboration of a <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> creates the discrete
subtype, and consists of the elaboration of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> or the
evaluation of the <FONT FACE="Arial, Helvetica">range</FONT>. The elaboration of a <FONT FACE="Arial, Helvetica">component_definition</FONT>
in an <FONT FACE="Arial, Helvetica">array_type_definition</FONT> consists of the elaboration of the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT>. The elaboration of any
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT>s and the elaboration of
the <FONT FACE="Arial, Helvetica">component_definition</FONT> are performed in an arbitrary order.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The elaboration of a <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> that does not contain
any per-object expressions creates the discrete
subtype, and consists of the elaboration of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> or the
evaluation of the <FONT FACE="Arial, Helvetica">range</FONT>. The elaboration of a
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> that contains one or more per-object
expressions is defined in 3.8. The elaboration of a <FONT FACE="Arial, Helvetica">component_definition</FONT>
in an <FONT FACE="Arial, Helvetica">array_type_definition</FONT> consists of the elaboration of the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT>. The elaboration of any
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT>s and the elaboration of
the <FONT FACE="Arial, Helvetica">component_definition</FONT> are performed in an arbitrary order.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.8(18):   </FONT></B></P>
<UL><P>Within the definition of a composite type, if a <FONT FACE="Arial, Helvetica">component_definition</FONT> or
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> (see 9.5.2) includes a <FONT FACE="Arial, Helvetica">name</FONT> that denotes
a discriminant of the type, or that is an <FONT FACE="Arial, Helvetica">attribute_reference</FONT> whose
<FONT FACE="Arial, Helvetica">prefix</FONT> denotes the current instance of the type, the expression containing
the <FONT FACE="Arial, Helvetica">name</FONT> is called a <I>per-object expression</I>, and the constraint being
defined is called a <I>per-object constraint</I>. For the elaboration of a
<FONT FACE="Arial, Helvetica">component_definition</FONT> of a <FONT FACE="Arial, Helvetica">component_declaration</FONT>, if the <FONT FACE="Arial, Helvetica">constraint</FONT>
of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> is not a per-object constraint, then the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT> is elaborated. On the other hand, if the <FONT FACE="Arial, Helvetica">constraint</FONT>
is a per-object constraint, then the elaboration consists of the evaluation
of any included expression that is not part of a per-object expression.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Within the definition of a composite type, if a <FONT FACE="Arial, Helvetica">component_definition</FONT> or
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> (see 9.5.2) includes a <FONT FACE="Arial, Helvetica">name</FONT> that denotes
a discriminant of the type, or that is an <FONT FACE="Arial, Helvetica">attribute_reference</FONT> whose
<FONT FACE="Arial, Helvetica">prefix</FONT> denotes the current instance of the type, the expression containing the
<FONT FACE="Arial, Helvetica">name</FONT> is called a <I>per-object expression</I>, and the <FONT FACE="Arial, Helvetica">constraint</FONT> or
<FONT FACE="Arial, Helvetica">range</FONT> being defined is called a <I>per-object constraint</I>. For the
elaboration of a <FONT FACE="Arial, Helvetica">component_definition</FONT> of a <FONT FACE="Arial, Helvetica">component_declaration</FONT> or
the <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> of an <FONT FACE="Arial, Helvetica">entry_declaration</FONT> for an entry
family (see 9.5.2), if the <FONT FACE="Arial, Helvetica">constraint</FONT> or <FONT FACE="Arial, Helvetica">range</FONT> of the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT> or <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> is not a per-object
constraint, then the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> or <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT>
is elaborated. On the other hand, if the <FONT FACE="Arial, Helvetica">constraint</FONT> or <FONT FACE="Arial, Helvetica">range</FONT> is a
per-object constraint, then the elaboration consists of the evaluation of any
included expression that is not part of a per-object expression. Each such
expression is evaluated once unless it is part of a named association in a
discriminant constraint, in which case it is evaluated once for each associated
discriminant.
</P></UL>
<UL><P>When a per-object constraint is elaborated (as part of creating an object),
each per-object expression of the constraint is evaluated.
For other expressions, the values determined during the elaboration of the
<FONT FACE="Arial, Helvetica">component_definition</FONT> or <FONT FACE="Arial, Helvetica">entry_declaration</FONT> are used. Any checks
associated with the enclosing <FONT FACE="Arial, Helvetica">subtype_indication</FONT> or
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> are performed, including the subtype
compatibility check (see 3.2.2), and the associated subtype is created.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.8(10):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
If the designated type is composite, an object of the designated
type is created with tag, if any, determined by the <FONT FACE="Arial, Helvetica">subtype_mark</FONT>
of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT>; any per-object constraints on
subcomponents are elaborated and any implicit initial values for
the subcomponents of the object are obtained as determined by the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT> and assigned to the corresponding subcomponents.
A check is made that the value of the object belongs to the designated
subtype. Constraint_Error is raised if this check fails. This check and the
initialization of the object are performed in an arbitrary order.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
If the designated type is composite, an object of the designated
type is created with tag, if any, determined by the <FONT FACE="Arial, Helvetica">subtype_mark</FONT>
of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT>; any per-object constraints on
subcomponents are elaborated (see 3.8) and any implicit initial values for
the subcomponents of the object are obtained as determined by the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT> and assigned to the corresponding subcomponents.
A check is made that the value of the object belongs to the designated
subtype. Constraint_Error is raised if this check fails. This check and the
initialization of the object are performed in an arbitrary order.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  9.5.2(22):   </FONT></B></P>
<UL><P>For the elaboration of an <FONT FACE="Arial, Helvetica">entry_declaration</FONT> for an entry family, if the
<FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> contains no per-object expressions (see 3.8),
then the <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> is elaborated. Otherwise, the
elaboration of the <FONT FACE="Arial, Helvetica">entry_declaration</FONT> consists of the evaluation of any
expression of the <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT> that is not a per-object
expression (or part of one). The elaboration of an <FONT FACE="Arial, Helvetica">entry_declaration</FONT> for a
single entry has no effect.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The elaboration of an <FONT FACE="Arial, Helvetica">entry_declaration</FONT> for an entry family consists of
the elaboration of the <FONT FACE="Arial, Helvetica">discrete_subtype_definition</FONT>, as described in 3.8.
The elaboration of an <FONT FACE="Arial, Helvetica">entry_declaration</FONT> for a single entry has no effect.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Notwithstanding the rules given in 3.3.1(18), 4.3.1(19), and 4.8(10),
the elaboration of the subtype indication of a component definition with
a per-object constraint occurs when an object of the enclosing type is
created.  This elaboration takes place on elaboration of an object
declaration, evaluation of an uninitialized allocator, and when
evaluating an aggregate of the type.
</P>
<P>The elaboration consists of the evaluation of each per-object expression
of the component's constraint, followed by the conversion of the value
of each expression of the constraint to its appropriate expected type
and the performance of the compatibility check defined for the elaboration
of the subtype indication (see 3.2.2(11)).  The values used for any
expressions that are not part of per-object expressions of the subtype's
constraint are those determined during the original elaboration of the
component definition as defined in 3.8(18).  Such expressions are not
reevaluated during elaboration of the per-object constraint that occurs
as part of object creation, despite any rules that state when a
per-object constraint is elaborated (e.g., as part of evaluating an
allocator or aggregate).
</P>
<P>Note further that the evaluation of expressions in a per-object constraint
defined in 3.8(18) was intended to take into account the case of named
associations for multiple components in a discriminant constraint.  For
such an association, the expression must be evaluated once for each
associated component, as prescribed by 3.7.1(12).
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>There are two basic problems with the current wording of the standard regarding
the elaboration of components with a per-object constraint. The
first is that the rules don't explain what is done with the values
obtained from expressions that are not part of per-object expressions
(as defined in 3.8(18)) or whether such expression are reevaluated when
a per-object constraint is later elaborated during object creation.
The other problem is that the mention of elaboration of per-object
constraints in rules such as 4.3.1(19) and 4.8(10) fails to cover
the need for the subtype compatibility check that is normally performed
when elaborating a subtype indication.
</P>
<P>The intent was clearly that the values of the expressions evaluated as
part of elaborating a component definition with a per-object constraint
(3.8(18)) should be used later when creating an object of the containing
type. It would not make sense to discard the values already determined
and to reevaluate the expressions (especially if they have side effects).
The description in the rules for allocator and aggregate evaluation
that states that a per-object constraint is elaborated should mention
that only the per-object expressions are evaluated at that point and
that the values for other expressions are those determined earlier
when the type was elaborated. (The description of the semantics
of elaborating per-object constraints should really be centralized
in a single place, such as 3.8(18).)
</P>
<P>The rules for object declarations, allocator evaluation, and aggregate
evaluation all fail to require the subtype compatibility check that
occurs when a subtype indication is elaborated (and for object declarations
even the constraint elaboration is omitted). This check is certainly
needed in these cases as well. The fix for this oversight is to define
each of these rules to include the elaboration of the subtype indications
for components with per-object constraints (which also subsumes the
elaboration of the constraint itself).
</P>
<P>One other minor gap is that the case of elaborating a named discriminant
association within a per-object constraint is not covered by that rule
in 3.8(18). The rule as given only describes a single evaluation for
each expression of the constraint, but the intent is that for a named
association the expression should be evaluated for each associated
component.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0003"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0003 -  Modular types on one's complement machines</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00095<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.5.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>How should an implementation on a one's complement machine implement
modular types intended to use all the bits of a full word?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Implementation Permission: On a one's complement machine, the
implementation may support non-binary moduli above
System.Max_Nonbinary_Modulus.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  3.5.4(27):   </FONT></B></P>
<UL><P>For a one's complement machine, the high bound of the base range of a
modular type whose modulus is one less than a power of 2 may be equal to the
modulus, rather than one less than the modulus. It is implementation defined
for which powers of 2, if any, this permission is exercised.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>For a one's complement machine, implementations may support non-binary modulus
values greater than System.Max_Nonbinary_Modulus. It is implementation defined
which specific values greater than System.Max_Nonbinary_Modulus, if any, are
supported.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Consider a 36-bit one's complement machine. One should be able to
declare a 36-bit modular type. For logical operations to make sense,
the all-ones bit pattern ought to be allowed, and should compare not
equal to zero, and greater than every other bit pattern. The
Implementation Permission in 3.5.4(27) is intended to allow this.
</P>
<P>On a 36-bit two's complement machine, one would declare:
</P>
<PRE><TT><UL><B>type</B> T <B>is</B> <B>mod</B> 2**36;
</UL></TT></PRE>
<P>and T'Modulus would be 2**36, and the base range of T would be 0..2**36-1.
If one says:
</P>
<PRE><TT><UL><B>type</B> TT <B>is</B> <B>mod</B> 2**36-1;
</UL></TT></PRE>
<P>TT'Modulus is 2**36-1, and the base range of TT is usually 0..2**36-2.
The implementation permission says that the base range of TT can
be 0..2**36-1.  This means that the all-ones bit pattern is a
valid value of the type, and is not reduced via the modulus.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0004"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0004 -  S'Digits when T'Machine_Radix is 10</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00203<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.5.8</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The relationship given in 3.5.8(2) in the case of T'Machine_Radix =
10 implies that S'Digits + 1 = T'Model_Mantissa in such a case. Is
this correct? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The relationship between S'Digits and T'Model_Mantissa given in
3.5.8(2) states that S'Digits is the largest value of d for which
</P>
<P><UL>ceiling(d * log(10) / log(T'Machine_Radix)) + 1 &lt;= T'Model_Mantissa
</UL></P>
<P>This allows for a &quot;guard digit&quot; which is necessary to take care of
extreme circumstances that arise if the Machine_Radix is not
decimal (as is usually the case).
</P>
<P>However, this guard digit is unnecessary if Machine_Radix is 10 or a
power of 10 and in such a case the relationship should read
</P>
<P><UL>ceiling(d * log(10) / log(T'Machine_Radix)) &lt;= T'Model_Mantissa
</UL></P>
<P>If Machine_Radix is 10 this becomes simply
</P>
<P><UL>d &lt;= T'Model_Mantissa
</UL></P>
<P>so that S'Digits = T'Model_Mantissa.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.5.8(2):   </FONT></B></P>
<P><UL><DL>
<DT>S'Digits<DD>S'Digits denotes the requested decimal precision for the
subtype S. The value of this attribute is of the type <I>universal_integer</I>. The
requested decimal precision of the base subtype of a floating point type T
is defined to be the largest value of <I>d</I> for which ceiling(<I>d</I> * log(10) /
log(T'Machine_Radix)) + 1 &lt;= T'Model_Mantissa.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>S'Digits<DD>S'Digits denotes the requested decimal precision for the
subtype S. The value of this attribute is of the type <I>universal_integer</I>.
The requested decimal precision of the base subtype of a floating point
type T is defined to be the largest value of <I>d</I> for which</DL></UL></P>
<P><UL><UL>
  ceiling(<I>d</I> * log(10) / log(T'Machine_Radix)) + <I>g</I> &lt;= T'Model_Mantissa<BR>
where <I>g</I> is 0 if Machine_Radix is a positive power of 10 and 1 otherwise.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This question echoes back to a change made between 1980 preliminary
Ada and the 1983 standard which is worth explaining as background.
</P>
<P>In Ada 83, the user specified a number D of decimal digits and the
implementation then provided model numbers using B binary digits.
Intuitively one might expect to need log 10 / log 2 (3.3219...) binary
digits for every decimal digit (with appropriate rounding up). The
1980 edition of the Ada Reference Manual (3.5.7 third paragraph) says
</P>
<P><UL>(B is the next integer above D*ln(10) / ln(2)).
</UL></P>
<P>So 1 decimal digit might be expected to be equivalent to 4 binary
digits, 2 decimal digits equivalent to 7 binary digits and so on.
But this is not enough. Four binary digits give a relative precision
of between 1 in 8 and 1 in 16 whereas one decimal digit requests a
maximum precision of 1 in 10. Thus there are places where the model
numbers for B = 4 are slightly too far apart.
</P>
<P>For example the decimal model numbers around 10000 for D = 1 are
</P>
<P><UL>8000  9000  10000  20000
</UL></P>
<P>whereas the binary model numbers for B = 4 are
</P>
<P><UL>7680  8192  9216  10240
</UL></P>
<P>and 8192 and 9216 are more than 1000 apart.
</P>
<P>This surprising behaviour resulted in the addition of one to the
formula so that 3.5.7(6) of Ada 83 concludes
</P>
<P><UL>(The number B is the integer next above (D*log(10) / log(2)) + 1.)
</UL></P>
<P>In Ada 95 this formula has been generalized to use T'Machine_Radix
rather than 2. However, the special case where Machine_Radix is 10
(or indeed a power of 10) has been overlooked since then no
anomalous situations can arise and the &quot;guard digit&quot; is not
required.
</P>
<P>The formula should therefore be adjusted accordingly.
</P>
<P>Note the peculiar phenomenon that more digits may be required for a
hexadecimal machine than a decimal machine. Thus one decimal digit
requires 2 hexadecimal digits.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0005"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0005 -  When is a Small clause allowed?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00054<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.5.10</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>3.5.9(8) says, &quot;For a type defined by an ordinary_fixed_point_definition
(an ordinary fixed point type), the small may be specified by an
attribute_definition_clause (see 13.3)&quot;.
</P>
<P>3.5.10(2) says, &quot;Small may be specified for nonderived fixed point types
via an attribute_definition_clause (see 13.3)&quot;.
</P>
<P>13.3(5) says, &quot;An attribute_designator is allowed in an
attribute_definition_clause only if this International Standard
explicitly allows it&quot;.
</P>
<P>What is the intent?  May Small be specified for a derived fixed point
type?  (No.)  May it be specified for a decimal type?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A Small clause is illegal for a decimal fixed point type.
A Small clause is illegal for a derived fixed point type.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.5.10(2):   </FONT></B></P>
<P><UL><DL>
<DT>S'Small<DD>S'Small denotes the <I>small</I> of the type of S. The value of
this attribute is of the type <I>universal_real</I>. Small may be specified for
nonderived fixed point types via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
(see 13.3); the expression of such a clause shall be static.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>S'Small<DD>S'Small denotes the <I>small</I> of the type of S. The value of
this attribute is of the type <I>universal_real</I>. Small may be specified for
nonderived ordinary fixed point types via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
(see 13.3); the expression of such a clause shall be static.</DL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A Small clause is illegal for a decimal fixed point type.
A Small clause is illegal for a derived fixed point type.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent was to disallow a Small clause for a decimal type,
because the Small is determined by the type declaration.
</P>
<P>The intent was to also disallow a Small clause for a derived fixed point
type, because otherwise the model numbers of the parent and derived
types might differ, resulting in semantic difficulties.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0006"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0006 -  The word "prefix" should be in sans serif font</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00030<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.6.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Shouldn't the word &quot;prefix&quot; be in the sans serif font? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The word &quot;prefix&quot; should be in the sans serif font.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.6.2(2):   </FONT></B></P>
<UL><P>The following attributes are defined for a prefix A that is of an array
type (after any implicit dereference), or denotes a constrained array
subtype:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The following attributes are defined for a <FONT FACE="Arial, Helvetica">prefix</FONT> A that is of an array
type (after any implicit dereference), or denotes a constrained array
subtype:
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This was an editing error.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0007"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0007 -  unknown_discriminant_parts on generic formal types</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00098<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.7</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>12.5(10) (a NOTE) says that &quot;A discriminant_part is allowed only for
certain kinds of types, and therefore only for certain kinds of generic
formal types.  See 3.7.&quot;
</P>
<P>Unfortunately, the rule in 3.7(8) only applies to
known_discriminant_parts.  3.7 does not contain any rule restricting the
usage of unknown_discriminant_parts.
</P>
<P>Various syntax rules usually do the job, but for generic formal types,
the syntax allows unknown_discriminant_parts.  Therefore, are the
following legal?  (No.)
</P>
<PRE><TT><UL><B>generic</B>
    <B>type</B> Disc (&lt;&gt;) <B>is</B> (&lt;&gt;); -- Illegal!
    <B>type</B> Flt  (&lt;&gt;) <B>is</B> <B>digits</B> (&lt;&gt;); -- Illegal!
    <B>type</B> Str  (&lt;&gt;) <B>is</B> <B>new</B> String; -- Illegal!
<B>procedure</B> ....
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A generic formal type must not have an unknown_discriminant_part,
unless the type is a composite non-array type.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.7(8):   </FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">known_discriminant_part</FONT> is only permitted in a declaration for a
composite type that is not an array type (this includes generic formal
types); a type declared with a <FONT FACE="Arial, Helvetica">known_discriminant_part</FONT> is called a
<I>discriminated</I> type, as is a type that inherits (known) discriminants.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">discriminant_part</FONT> is only permitted in a declaration for a
composite type that is not an array type (this includes generic formal
types). A type declared with a <FONT FACE="Arial, Helvetica">known_discriminant_part</FONT> is called a
<I>discriminated</I> type, as is a type that inherits (known) discriminants.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is that elementary and array types cannot have discriminant
parts (known or unknown).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0008"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0008 -  Aliased objects cannot have discriminants modified</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00168<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.7.1;  4.6</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider the following code fragment:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
   <B>pragma</B> Elaborate_Body;
   <B>type</B> T <B>is</B> <B>private</B>;
   A : <B>constant</B> T;
<B>private</B>
   <B>type</B> T (D : Integer := 0) <B>is</B> <B>null</B> <B>record</B>;
   <B>type</B> Ptr <B>is</B> <B>access</B> <B>all</B> T;
   A : <B>constant</B> T := (D =&gt; 1);
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> P;
<B>package</B> Q <B>is</B>
   <B>type</B> A1 <B>is</B> <B>array</B> (1 .. 10) <B>of</B> <B>aliased</B> P.T;
   <B>type</B> A2 <B>is</B> <B>array</B> (1 .. 10) <B>of</B> P.T;
   X : A1;
<B>end</B> Q;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> P, Q;
<B>procedure</B> R <B>is</B>
   <B>procedure</B> S (Y : <B>in</B> <B>out</B> Q.A2) <B>is</B>
   <B>begin</B>
      Y (1) := P.A;
   <B>end</B>;
<B>begin</B>
   S (Q.A2 (Q.X)); -- This call will change the discriminant of Q.X (1)
<B>end</B>;
</UL></TT></PRE>
<P>This example illustrates a case where it is possible to change the
discriminant of an aliased component of an object, which is supposed to be
forbidden.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A view conversion of an array object is illegal if the target subtype and
the operand do not have both aliased components or both non-aliased components.
</P>
<P>A discriminant constraint for a general access type is illegal if there are
places where the designated subtype appears constrained and others where it
appears unconstrained.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.7.1(7):   </FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">discriminant_constraint</FONT> is only allowed in a <FONT FACE="Arial, Helvetica">subtype_indication</FONT>
whose <FONT FACE="Arial, Helvetica">subtype_mark</FONT> denotes either an unconstrained discriminated subtype,
or an unconstrained access subtype whose designated subtype is an unconstrained
discriminated subtype.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">discriminant_constraint</FONT> is only allowed in a <FONT FACE="Arial, Helvetica">subtype_indication</FONT> whose
<FONT FACE="Arial, Helvetica">subtype_mark</FONT> denotes either an unconstrained discriminated subtype, or an
unconstrained access subtype whose designated subtype is an unconstrained
discriminated subtype. However, in the case of a general access subtype, a
<FONT FACE="Arial, Helvetica">discriminant_constraint</FONT> is illegal if there is a place within the
immediate scope of the designated subtype where the designated subtype's view
is constrained.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.6(11):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
Corresponding index types shall be convertible; and</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
Corresponding index types shall be convertible;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.6(12):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
The component subtypes shall statically match.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
The component subtypes shall statically match; and</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
In a view conversion, the target type and the operand type shall both
or neither have aliased components.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The problem (1) comes from the fact that it is possible to use a view
conversion to convert an array object with aliased components to an array type
with non-aliased components.  Such a conversion must be disallowed.
</P>
<P>The ARG also discussed the following example, which illustrates another case
where the standard seems to allow a discriminant to be changed:
</P>
<PRE><TT><UL><B>with</B> Q;
<B>package</B> <B>body</B> P <B>is</B>
   PT : Ptr (0) := Q.X (1)'<B>access</B>;
<B>begin</B>
   Q.X := (<B>others</B> =&gt; (D =&gt; 2)); -- Changes the discriminant of Q.X (2)
<B>end</B> P;
</UL></TT></PRE>
<P>The root of problem (2) is that there are places (e.g., the visible part of P)
where P.T is constrained, but other places (e.g., the private part and body of
P) where P.T is unconstrained.  This causes privacy problems when applying the
following rule:
</P>
<P>&quot;if a component_definition contains the reserved word aliased and the type of
the component is discriminated, then the nominal subtype of the component
shall be constrained.&quot; (3.6(11))
</P>
<P>Also note that the problem exists with non-private types, provided that the
characteristic that the type is unconstrained is not visible everywhere:
</P>
<PRE><TT><UL><B>package</B> P.C <B>is</B>
   <B>type</B> NT <B>is</B> <B>new</B> T;
<B>private</B>
   <B>type</B> Ptr <B>is</B> <B>access</B> <B>all</B> NT; -- Causes the same problems as P.Ptr.
<B>end</B> P.C;
</UL></TT></PRE>
<P>One way to fix this problem would be to require a component-by-component check
on the assignment to Q.X, but that would be very expensive.  Moreover, a
compile-time check would clearly be better than a run-time check.
</P>
<P>Aliasedness of the components is not really what is causing trouble, though.
It is really the existence of a general access type, and in fact of a
discriminant constraint on such an access type, which causes trouble.  Thus,
forbidding such a constraint is the chosen solution, especially
considering that constraints on access types are not a terribly useful
feature.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0009"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0009 -  Attribute definition clause for stream attributes</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00137<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.8;  3.11;  9.1;  9.4;  13;  13.1;  13.3;  13.4;  13.11;  13.13.2;  13.14</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>13.1(10) seems to forbid the following example:
</P>
<PRE><TT><UL><B>with</B> Ada.Streams; <B>use</B> Ada.Streams;
<B>generic</B>
  <B>type</B> T <B>is</B> <B>private</B>;
<B>package</B> Attr_Rep <B>is</B>
  <B>type</B> NT <B>is</B> <B>new</B> T;
  <B>procedure</B> Attribute_Write(
            Stream : <B>access</B> Root_Stream_Type'Class;
            Item   : <B>in</B> NT);
  <B>for</B> NT'Write <B>use</B> Attribute_Write; -- Illegal?  (No.)
<B>end</B> Attr_Rep;
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>13.1(10) says:
</P>
<P><UL>For an untagged derived type, no type-related representation items are
allowed if the parent type is a by-reference type, or has any user-defined
primitive subprograms.
</UL></P>
<P>This rule does not apply to an attribute_definition_clause for one of
the stream-oriented attributes Read, Write, Input, and Output.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.8(5):   </FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">component_item ::= component_declaration | representation_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">component_item ::= component_declaration | aspect_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.11(4):   </FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">basic_declarative_item ::=
     basic_declaration | representation_clause | use_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">basic_declarative_item ::=
     basic_declaration | aspect_clause | use_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  9.1(5):   </FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">task_item ::= entry_declaration | representation_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">task_item ::= entry_declaration | aspect_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  9.1(12):   </FONT></B></P>
<UL><P>As part of the initialization of a task object, any <FONT FACE="Arial, Helvetica">representation_clause</FONT>s
and any per-object constraints associated with <FONT FACE="Arial, Helvetica">entry_declaration</FONT>s of
the corresponding <FONT FACE="Arial, Helvetica">task_definition</FONT> are elaborated in the given order.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>As part of the initialization of a task object, any <FONT FACE="Arial, Helvetica">aspect_clause</FONT>s
and any per-object constraints associated with <FONT FACE="Arial, Helvetica">entry_declaration</FONT>s of
the corresponding <FONT FACE="Arial, Helvetica">task_definition</FONT> are elaborated in the given order.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  9.4(5):   </FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">protected_operation_declaration ::= subprogram_declaration
         | entry_declaration
         | representation_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">protected_operation_declaration ::= subprogram_declaration
         | entry_declaration
         | aspect_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  9.4(8):   </FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">protected_operation_item ::= subprogram_declaration
         | subprogram_body
         | entry_body
         | representation_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">protected_operation_item ::= subprogram_declaration
         | subprogram_body
         | entry_body
         | aspect_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13(1):   </FONT></B></P>
<UL><P>This section describes features for querying and controlling aspects of
representation and for interfacing to hardware.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>This section describes features for querying and controlling certain aspects
of entities and for interfacing to hardware.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace the title of  13.1:   </FONT></B></P>
<UL><P>Representation Items
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Operational and Representation Items
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(1):   </FONT></B></P>
<UL><P>There are three kinds of <I>representation items</I>: <FONT FACE="Arial, Helvetica">representation_clause</FONT>s,
<FONT FACE="Arial, Helvetica">component_clause</FONT>s, and <I>representation pragmas</I>. Representation items
specify how the types and other entities of the language are to be mapped onto
the underlying machine. They can be provided to give more efficient
representation or to interface with features that are outside the domain of
the language (for example, peripheral hardware). Representation items also
specify other specifiable properties of entities. A representation item
applies to an entity identified by a <FONT FACE="Arial, Helvetica">local_name</FONT>, which denotes an entity
declared local to the current declarative region, or a library unit declared
immediately preceding a representation pragma in a <FONT FACE="Arial, Helvetica">compilation</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Representation and operational items can be used to specify aspects of
entities. Two kinds of aspects of entities can be specified: aspects of
representation and operational aspects. Representation items specify how the
types and other entities of the language are to be mapped onto the
underlying machine. Operational items specify other properties of entities.
</P></UL>
<UL><P>There are six kinds of <I>representation items</I>:
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>s for representation attributes,
<FONT FACE="Arial, Helvetica">enumeration_representation_clause</FONT>s, <FONT FACE="Arial, Helvetica">record_representation_clause</FONT>s,
<FONT FACE="Arial, Helvetica">at_clause</FONT>s, <FONT FACE="Arial, Helvetica">component_clause</FONT>s, and <I>representation pragmas</I>.
They can be provided to give more efficient
representation or to interface with features that are outside the domain of
the language (for example, peripheral hardware).
</P></UL>
<UL><P>An <I>operational item</I> is an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT> for an
operational attribute.
</P></UL>
<UL><P>An operational item or a representation item applies to an entity
identified by a <FONT FACE="Arial, Helvetica">local_name</FONT>, which denotes an entity declared local to the
current declarative region, or a library unit declared immediately preceding a
representation pragma in a <FONT FACE="Arial, Helvetica">compilation</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(2):   </FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">representation_clause ::= attribute_definition_clause
      | enumeration_representation_clause
      | record_representation_clause
      | at_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><FONT FACE="Arial, Helvetica">aspect_clause ::= attribute_definition_clause
      | enumeration_representation_clause
      | record_representation_clause
      | at_clause</FONT></TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(4):   </FONT></B></P>
<P><UL><UL>
A representation pragma is allowed only at places where a
<FONT FACE="Arial, Helvetica">representation_clause</FONT> or <FONT FACE="Arial, Helvetica">compilation_unit</FONT> is allowed.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
A representation pragma is allowed only at places where an
<FONT FACE="Arial, Helvetica">aspect_clause</FONT> or <FONT FACE="Arial, Helvetica">compilation_unit</FONT> is allowed.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(5):   </FONT></B></P>
<UL><P>In a representation item, if the <FONT FACE="Arial, Helvetica">local_name</FONT> is a <FONT FACE="Arial, Helvetica">direct_name</FONT>, then it
shall resolve to denote a declaration (or, in the case of a <FONT FACE="Arial, Helvetica">pragma</FONT>, one or
more declarations) that occurs immediately within the same
<FONT FACE="Arial, Helvetica">declarative_region</FONT> as the representation item. If the <FONT FACE="Arial, Helvetica">local_name</FONT> has
an <FONT FACE="Arial, Helvetica">attribute_designator</FONT>, then it shall resolve to denote an
implementation-defined component (see 13.5.1) or a class-wide type implicitly
declared immediately within the same <FONT FACE="Arial, Helvetica">declarative_region</FONT> as the
representation item. A <FONT FACE="Arial, Helvetica">local_name</FONT> that is a
<I>library_unit_</I><FONT FACE="Arial, Helvetica">name</FONT> (only permitted in a representation pragma) shall
resolve to denote the <FONT FACE="Arial, Helvetica">library_item</FONT> that immediately precedes (except for
other pragmas) the representation pragma.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>In an operational item or representation item, if the <FONT FACE="Arial, Helvetica">local_name</FONT> is a
<FONT FACE="Arial, Helvetica">direct_name</FONT>, then it shall resolve to denote a declaration (or, in the
case of a <FONT FACE="Arial, Helvetica">pragma</FONT>, one or more declarations) that occurs immediately
within the same <FONT FACE="Arial, Helvetica">declarative_region</FONT> as the item. If the <FONT FACE="Arial, Helvetica">local_name</FONT>
has an <FONT FACE="Arial, Helvetica">attribute_designator</FONT>, then it shall resolve to denote an
implementation-defined component (see 13.5.1) or a class-wide type implicitly
declared immediately within the same <FONT FACE="Arial, Helvetica">declarative_region</FONT> as the
item. A <FONT FACE="Arial, Helvetica">local_name</FONT> that is a
<I>library_unit_</I><FONT FACE="Arial, Helvetica">name</FONT> (only permitted in a representation pragma) shall
resolve to denote the <FONT FACE="Arial, Helvetica">library_item</FONT> that immediately precedes (except for
other pragmas) the representation pragma.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(6):   </FONT></B></P>
<UL><P>The <FONT FACE="Arial, Helvetica">local_name</FONT> of a <FONT FACE="Arial, Helvetica">representation_clause</FONT> or representation pragma
shall statically denote an entity (or, in the case of a <FONT FACE="Arial, Helvetica">pragma</FONT>, one or
more entities) declared immediately preceding it in a <FONT FACE="Arial, Helvetica">compilation</FONT>, or
within the same <FONT FACE="Arial, Helvetica">declarative_part</FONT>, <FONT FACE="Arial, Helvetica">package_specification</FONT>,
<FONT FACE="Arial, Helvetica">task_definition</FONT>, <FONT FACE="Arial, Helvetica">protected_definition</FONT>, or <FONT FACE="Arial, Helvetica">record_definition</FONT>
as the representation item. If a <FONT FACE="Arial, Helvetica">local_name</FONT> denotes a local callable
entity, it may do so through a local <FONT FACE="Arial, Helvetica">subprogram_renaming_declaration</FONT>
(as a way to resolve ambiguity in the presence of overloading); otherwise, the
<FONT FACE="Arial, Helvetica">local_name</FONT> shall not denote a <FONT FACE="Arial, Helvetica">renaming_declaration</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The <FONT FACE="Arial, Helvetica">local_name</FONT> of an <FONT FACE="Arial, Helvetica">aspect_clause</FONT> or representation pragma
shall statically denote an entity (or, in the case of a <FONT FACE="Arial, Helvetica">pragma</FONT>, one or
more entities) declared immediately preceding it in a <FONT FACE="Arial, Helvetica">compilation</FONT>, or
within the same <FONT FACE="Arial, Helvetica">declarative_part</FONT>, <FONT FACE="Arial, Helvetica">package_specification</FONT>,
<FONT FACE="Arial, Helvetica">task_definition</FONT>, <FONT FACE="Arial, Helvetica">protected_definition</FONT>, or <FONT FACE="Arial, Helvetica">record_definition</FONT>
as the representation or operational item. If a <FONT FACE="Arial, Helvetica">local_name</FONT> denotes a
local callable entity, it may do so through a local
<FONT FACE="Arial, Helvetica">subprogram_renaming_declaration</FONT> (as a way to resolve ambiguity in the
presence of overloading); otherwise, the <FONT FACE="Arial, Helvetica">local_name</FONT> shall not denote a
<FONT FACE="Arial, Helvetica">renaming_declaration</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.1(8):   </FONT></B></P>
<UL><P>A representation item <I>directly specifies</I> an <I>aspect of representation</I> of
the entity denoted by the <FONT FACE="Arial, Helvetica">local_name</FONT>, except in the case of a type-related
representation item, whose <FONT FACE="Arial, Helvetica">local_name</FONT> shall denote a first subtype, and
which directly specifies an aspect of the subtype's type. A representation
item that names a subtype is either <I>subtype-specific</I> (Size and Alignment
clauses) or <I>type-related</I> (all others). Subtype-specific aspects may differ
for different subtypes of the same type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>An operational item <I>directly specifies</I> an <I>operational aspect</I> of the
type of the subtype denoted by the <FONT FACE="Arial, Helvetica">local_name</FONT>. The <FONT FACE="Arial, Helvetica">local_name</FONT> of an
operational item shall denote a first subtype. An operational item that names
a subtype is type-related.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.1(9):   </FONT></B></P>
<UL><P>A representation item that directly specifies an aspect of a subtype or
type shall appear after the type is completely defined (see 3.11.1), and
before the subtype or type is frozen (see 13.14). If a representation item
is given that directly specifies an aspect of an entity, then it is illegal
to give another representation item that directly specifies the same aspect
of the entity.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>An operational item that directly specifies an aspect of a type shall appear
before the type is frozen (see 13.14). If an operational item is given that
directly specifies an aspect of a type, then it is illegal to give another
operational item that directly specifies the same aspect of the type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(11):   </FONT></B></P>
<UL><P>Representation aspects of a generic formal parameter are the same as
those of the actual. A type-related representation item is not allowed for a
descendant of a generic formal untagged type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Operational and representation aspects of a generic formal parameter are the
same as those of the actual. A type-related representation item is not allowed
for a descendant of a generic formal untagged type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(13):   </FONT></B></P>
<UL><P>A representation item that is not supported by the implementation is illegal,
or raises an exception at run time.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A representation or operational item that is not supported by the
implementation is illegal, or raises an exception at run time.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(19):   </FONT></B></P>
<UL><P>For the elaboration of a <FONT FACE="Arial, Helvetica">representation_clause</FONT>, any evaluable constructs
within it are evaluated.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For the elaboration of an <FONT FACE="Arial, Helvetica">aspect_clause</FONT>, any evaluable constructs
within it are evaluated.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace the title of  13.3:   </FONT></B></P>
<UL><P>Representation Attributes
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Operational and Representation Attributes
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.3(1):   </FONT></B></P>
<UL><P>The values of certain implementation-dependent characteristics can be
obtained by interrogating appropriate representation attributes. Some of
these attributes are specifiable via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The values of certain implementation-dependent characteristics can be obtained
by interrogating appropriate operational or representation attributes. Some of
these attributes are specifiable via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.3(5):   </FONT></B></P>
<UL><P>An <FONT FACE="Arial, Helvetica">attribute_designator</FONT> is allowed in an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
only if this International Standard explicitly allows it, or for an
implementation-defined attribute if the implementation allows it. Each
specifiable attribute constitutes an aspect of representation.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An <FONT FACE="Arial, Helvetica">attribute_designator</FONT> is allowed in an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
only if this International Standard explicitly allows it, or for an
implementation-defined attribute if the implementation allows it. Each
specifiable attribute constitutes an operational aspect or an aspect of
representation.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.3(9):   </FONT></B></P>
<UL><P>The following attributes are defined:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The following representation attributes are defined: Address, Alignment, Size,
Storage_Size, and Component_Size.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.3(74):   </FONT></B></P>
<UL><P>For every subtype S of a tagged type T (specific or class-wide), the following
attribute is defined:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The following operational attribute is defined: External_Tag.
</P></UL>
<UL><P>For every subtype S of a tagged type T (specific or class-wide):
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.4(11):   </FONT></B></P>
<P><UL><UL>
NOTES<BR>
11 Unchecked_Conversion may be used to query the internal codes used
for an enumeration type. The attributes of the type, such as Succ,
Pred, and Pos, are unaffected by the <FONT FACE="Arial, Helvetica">representation_clause</FONT>. For
example, Pos always returns the position number, <I>not</I> the internal
integer code that might have been specified in a <FONT FACE="Arial, Helvetica">representation_clause</FONT>.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
NOTES<BR>
11 Unchecked_Conversion may be used to query the internal codes used
for an enumeration type. The attributes of the type, such as Succ,
Pred, and Pos, are unaffected by the <FONT FACE="Arial, Helvetica">enumeration_representation_clause</FONT>. For
example, Pos always returns the position number, <I>not</I> the internal
integer code that might have been specified in an
<FONT FACE="Arial, Helvetica">enumeration_representation_clause</FONT>.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.11(12):   </FONT></B></P>
<UL><P>For every access subtype S, the following attributes are defined:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For every access subtype S, the following representation attributes are defined:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.13.2(1):   </FONT></B></P>
<UL><P>The Write, Read, Output, and Input attributes convert values to a
stream of elements and reconstruct values from a stream.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The operational attributes Write, Read, Output, and Input convert values to a
stream of elements and reconstruct values from a stream.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.14(19):   </FONT></B></P>
<UL><P>A representation item that directly specifies an aspect of an entity shall
appear before the entity is frozen (see 13.1).
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An operational item or a representation item that directly specifies an
aspect of an entity shall appear before the entity is frozen (see 13.1).
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent of 13.1(10) is to forbid two types from having different
representation in certain cases. However, the stream-oriented
attributes, although they are formally defined to be &quot;representation
attributes&quot;, do not actually affect the representation of the type.
Therefore, there is no need for 13.1(10) to apply to these attributes.
Furthermore, as the example illustrates, applying the rule to these
attributes would seriously hinder their usefulness.
</P>
<P>The definition of stream attributes as &quot;representation attributes&quot; has
proven to be a continuing problem. Several issues have made it necessary
to exempt stream attributes from the rules for representation attributes;
indeed the number of such exemptions makes it clear that it is confusing to
classify them as representation attributes. Therefore,
we have taken the major step of defining a new kind of attribute, the
&quot;operational attributes&quot;, and redefining stream attributes to be of this kind.
</P>
<P>In particular, 7.3(5), 13.1(10), and the last sentence of 13.1(11) are
unchanged, so that these rules do not apply to operational items. None
of these rules are necessary for these attributes. We've also left 3.8(11)
unchanged, as an operational item cannot occur here. Changes to 13.1(15) and
13.1(18) are found in 8652/0040 (AI-00108).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0010"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0010 -  Expected type of a 'Access attribute</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00127<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.9.2;  3.10.2;  4.8</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider the following code fragment:
</P>
<PRE><TT><UL><B>type</B> T <B>is</B> <B>tagged</B> <B>null</B> <B>record</B>;
<B>procedure</B> P(X : <B>access</B> T);
Y : <B>aliased</B> T'Class := ...;
<B>type</B> T_Ptr <B>is</B> <B>access</B> <B>all</B> T'Class;
Z : T_Ptr;
</UL></TT></PRE>
<PRE><TT><UL>P(Y'<B>access</B>); -- (1) Legal?  (Yes.)
P(<B>new</B> T'Class'(...)); -- (2) Legal?  (Yes.)
P(Z); -- (3) Legal.
</UL></TT></PRE>
<P>The call at (3) is clearly legal, and is a dispatching call.
</P>
<P>However, the call at (1) appears to be illegal. The expected type for
Y'Access is the anonymous type &quot;access T&quot;, by 6.4.1(3). 3.10.2(24)
says, &quot;If the designated type of A [here, A is the anonymous access
type] is tagged, then the type of the view [Y] shall be covered by the
designated type&quot;. The type of the view is T'Class, which is not covered
by the designated type, which is T. Therefore, Y'Access is illegal
here.
</P>
<P>The call at (2) appears to be illegal for the same reason.
</P>
<P>It would seem that the same rules should apply to all of these calls;
(1) and (2) should be legal, and should be dispatching calls.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An attribute reference of the Access attribute may be used as the actual
parameter in a dispatching call, if the formal is an access parameter
designating a tagged type, and the prefix of the attribute reference is
of the corresponding class-wide type. Such an actual is considered to
be dynamically tagged.
</P>
<P>An analogous rule applies to an attribute reference of Unchecked_Access
and to an allocator.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.9.2(7):   </FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">type_conversion</FONT> is statically or dynamically tagged according to whether
the type determined by the <FONT FACE="Arial, Helvetica">subtype_mark</FONT> is specific or class-wide,
respectively. For a controlling operand that is designated by an actual
parameter, the controlling operand is statically or dynamically tagged
according to whether the designated type of the actual parameter is specific
or class-wide, respectively.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">type_conversion</FONT> is statically or dynamically tagged according to whether
the type determined by the <FONT FACE="Arial, Helvetica">subtype_mark</FONT> is specific or class-wide,
respectively. For an object that is designated by an expression whose
expected type is an anonymous access-to-specific tagged type, the object
is dynamically tagged if the expression, ignoring enclosing parentheses, is
of the form X'Access, where X is of a class-wide type, or is of the form
<B>new</B> T'(...), where T denotes a class-wide subtype. Otherwise, the object is
statically or dynamically tagged according to whether the designated type of
the type of the expression is specific or class-wide, respectively.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.9.2(9):   </FONT></B></P>
<UL><P>If the expected type for an expression or <FONT FACE="Arial, Helvetica">name</FONT> is some specific tagged
type, then the expression or <FONT FACE="Arial, Helvetica">name</FONT> shall not be dynamically tagged unless it
is a controlling operand in a call on a dispatching operation. Similarly, if
the expected type for an expression is an anonymous access-to-specific tagged
type, then the expression shall not be of an access-to-class-wide type unless
it designates a controlling operand in a call on a dispatching operation.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>If the expected type for an expression or <FONT FACE="Arial, Helvetica">name</FONT> is some specific tagged
type, then the expression or <FONT FACE="Arial, Helvetica">name</FONT> shall not be dynamically tagged unless
it is a controlling operand in a call on a dispatching operation.
Similarly, if the expected type for an expression is an anonymous
access-to-specific tagged type, then the object designated by the expression
shall not be dynamically tagged unless it is a controlling operand in
a call on a dispatching operation.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.10.2(24):   </FONT></B></P>
<P><UL><DL>
<DT>X'Access<DD>
X'Access yields an access value that designates the object
denoted by X. The type of X'Access is an access-to-object
type, as determined by the expected type. The expected type
shall be a general access type. X shall denote an aliased
view of an object, including possibly the current instance
(see 8.6) of a limited type within its definition, or a
formal parameter or generic formal object of a tagged type.
The view denoted by the <FONT FACE="Arial, Helvetica">prefix</FONT> X shall satisfy the following
additional requirements, presuming the expected type for
X'Access is the general access type <I>A</I>:</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>X'Access<DD>
X'Access yields an access value that designates the object
denoted by X. The type of X'Access is an access-to-object
type, as determined by the expected type. The expected type
shall be a general access type. X shall denote an aliased
view of an object, including possibly the current instance
(see 8.6) of a limited type within its definition, or a
formal parameter or generic formal object of a tagged type.
The view denoted by the <FONT FACE="Arial, Helvetica">prefix</FONT> X shall satisfy the following
additional requirements, presuming the expected type for
X'Access is the general access type <I>A</I>, with designated type <I>D</I>:</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.10.2(27):   </FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
If the designated type of <I>A</I> is tagged, then the type of the view
shall be covered by the designated type; if <I>A</I>'s designated type is not
tagged, then the type of the view shall be the same, and either <I>A</I>'s
designated subtype shall statically match the nominal subtype of the view,
or the designated subtype shall be discriminated and unconstrained;</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
If <I>A</I> is a named access type and <I>D</I> is a tagged type, then the
type of the view shall be covered by <I>D</I>; if <I>A</I> is anonymous and <I>D</I> is
tagged, then the type of the view shall be either <I>D</I>'Class or a type
covered by <I>D</I>; if <I>D</I> is untagged, then the type of the view shall be
<I>D</I>, and <I>A</I>'s designated subtype shall either statically match the
nominal subtype of the view or be discriminated and unconstrained;</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.8(3):   </FONT></B></P>
<UL><P>The expected type for an <FONT FACE="Arial, Helvetica">allocator</FONT> shall be a single access-to-object
type whose designated type covers the type determined by the <FONT FACE="Arial, Helvetica">subtype_mark</FONT>
of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> or <FONT FACE="Arial, Helvetica">qualified_expression</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The expected type for an <FONT FACE="Arial, Helvetica">allocator</FONT> shall be a single access-to-object type with
designated type <I>D</I> such that either <I>D</I> covers the type determined by the
<FONT FACE="Arial, Helvetica">subtype_mark</FONT> of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> or <FONT FACE="Arial, Helvetica">qualified_expression</FONT>,
or the expected type is anonymous and the determined type is <I>D</I>'Class.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The rules should be equivalent in these cases; anything else would be
surprising to the programmer. This is achieved by the above wording.
</P>
<P>In the call at (1), Y'Access is of the anonymous type &quot;access T&quot;.
Y'Access is dynamically tagged, despite the fact that its type's
designated type is not class-wide.
</P>
<P>In the call at (2), new T'Class'(...) is also of the anonymous type
&quot;access T&quot;, and is also dynamically tagged.
</P>
<P>Thus, all three calls are legal, and are dispatching calls to P.
</P>
<P>No wording changes are needed for Unchecked_Access, since it is already
defined in terms of Access.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0011"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0011 -  Calling conventions</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00117<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.9.2;  6.3.1;  13.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>6.3.1(2-13) define the default convention of various entities (that is, the
convention in the absence of a convention-specifying pragma):
</P>
<P><UL>As explained in B.1, ``Interfacing Pragmas'', a convention can be
specified for an entity.  For a callable entity or access-to-subprogram type,
the convention is called the calling convention.  The following conventions
are defined by the language:
</UL></P>
<P><UL><UL>The default calling convention for any subprogram not listed
below is Ada.  A pragma Convention, Import, or Export may be used
to override the default calling convention (see B.1).
</UL></UL></P>
<P><UL><UL>The Intrinsic calling convention represents subprograms that are
``built in'' to the compiler.  The default calling convention is
Intrinsic for the following:
</UL></UL></P>
<P><UL><UL>an enumeration literal;
</UL></UL></P>
<P><UL><UL>a &quot;/=&quot; operator declared implicitly due to the declaration
of &quot;=&quot; (see 6.6);
</UL></UL></P>
<P><UL><UL>any other implicitly declared subprogram unless it is a
dispatching operation of a tagged type;
</UL></UL></P>
<P><UL><UL>an inherited subprogram of a generic formal tagged type
with unknown discriminants;
</UL></UL></P>
<P><UL><UL>an attribute that is a subprogram;
</UL></UL></P>
<P><UL><UL>a subprogram declared immediately within a protected_body.
</UL></UL></P>
<P><UL><UL>The Access attribute is not allowed for Intrinsic
subprograms.
</UL></UL></P>
<P><UL>The default calling convention is protected for a protected
subprogram, and for an access-to-subprogram type with the
reserved word protected in its definition.
</UL></P>
<P><UL>The default calling convention is entry for an entry.
</UL></P>
<P>-----------------
</P>
<P>1. What is the default convention of an entity not covered by 6.3.1,
such as a record type?  (Ada.)
</P>
<P>-----------------
</P>
<P>2. Does an inherited or overriding subprogram have (by default) the same
convention as the parent subprogram?  (Yes.)
</P>
<P>6.3.1(3) implies that if the calling convention of a parent subprogram
is not Ada, the default convention of an overriding subprogram is,
nonetheless, Ada.  However, 3.9.2(10) says:
</P>
<P><UL>If the dispatching operation overrides an inherited subprogram, it
shall be subtype conformant with the inherited subprogram.
</UL></P>
<P>6.3.1(17) requires matching conventions for subtype conformance.
Thus, the <I>default</I> calling convention for this overriding case
is illegal; the programmer <I>must</I> give a pragma specifying the
convention in this case.  This seems unfriendly.
</P>
<P>On the other hand, 3.4(18) says:
</P>
<P><UL>The profile of an inherited subprogram (including an
inherited enumeration literal) is obtained from the profile of
the corresponding (user-defined) primitive subprogram of the
parent type, after systematic replacement of each subtype of its
profile (see 6.1) that is of the parent type with a corresponding
subtype of the derived type. ...
</UL></P>
<P>And 6.1(22) says:
</P>
<P><UL>Associated with a profile is a calling convention.
</UL></P>
<P>These paragraphs seem to imply that an inherited subprogram inherits the
calling convention of its parent, as part of the inherited profile.
</P>
<P>-----------------
</P>
<P>3. Is an implicitly declared dispatching &quot;/=&quot; operator legal?  (Yes.)
</P>
<P>Paragraph 3.9.1(1) says that the primitive subprograms of a tagged
type are called dispatching operations.  Paragraph 3.9.2(10) goes
on to say that a dispatching operation shall not be of convention
Intrinsic.  However, paragraph 6.3.1(6) says that &quot;/=&quot; declared
implicitly due to the declaration of &quot;=&quot; is of convention Intrinsic,
by default.
</P>
<P>Together these imply that the &quot;/=&quot; implicitly declared due to the
declaration of &quot;=&quot; of a tagged type is an illegal dispatching operation.
Is this the intent?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Unless specified otherwise in the standard, the default convention of any
entity is Ada.
</P>
<P>An inherited or overriding subprogram of a type extension inherits the
calling convention of the parent subprogram.
</P>
<P>New operations of type extensions have the convention of their type
unless a new convention is defined for the operation, if this is
supported by an implementation.
</P>
<P>The convention of the partial view of a private type or private
extension is the convention of the full type.
</P>
<P>An explicitly declared dispatching operation shall not have convention
Intrinsic. However, an implicitly declared dispatching &quot;/=&quot; operator with
Boolean result legally has convention Intrinsic.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.9.2(10):   </FONT></B></P>
<UL><P>In the declaration of a dispatching operation of a tagged type,
everywhere a subtype of the tagged type appears as a subtype of the profile
(see 6.1), it shall statically match the first subtype of the tagged type.
If the dispatching operation overrides an inherited subprogram, it shall be
subtype conformant with the inherited subprogram. A dispatching operation
shall not be of convention Intrinsic. If a dispatching operation overrides
the predefined equals operator, then it shall be of convention Ada (either
explicitly or by default -- see 6.3.1).
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>In the declaration of a dispatching operation of a tagged type,
everywhere a subtype of the tagged type appears as a subtype of the profile
(see 6.1), it shall statically match the first subtype of the tagged type.
If the dispatching operation overrides an inherited subprogram, it shall be
subtype conformant with the inherited subprogram. The convention of an
inherited or overriding dispatching operation is the convention of the
corresponding primitive operation of the parent type. An explicitly declared
dispatching operation shall not be of convention Intrinsic.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  6.3.1(2):   </FONT></B></P>
<UL><P>As explained in B.1, ``Interfacing Pragmas'', a
<I>convention</I> can be specified for an entity. For a callable entity
or access-to-subprogram type, the convention is called the
<I>calling convention</I>. The following conventions are defined by the language:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>As explained in B.1, ``Interfacing Pragmas'', a
<I>convention</I> can be specified for an entity. Unless this International
Standard states otherwise, the default convention of an entity is Ada. For
a callable entity or access-to-subprogram type, the convention is called the
<I>calling convention</I>. The following calling conventions are defined by the
language:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  6.3.1(13):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
The default calling convention is <I>entry</I> for an entry.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
If not specified above as Intrinsic, the calling convention for
any inherited or overriding dispatching operation of a tagged type is that
of the corresponding subprogram of the parent type. The
default calling convention for a new dispatching operation
of a tagged type is the convention of the type.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(11):   </FONT></B></P>
<UL><P>Representation aspects of a generic formal parameter are the same as
those of the actual. A type-related representation item is not allowed for a
descendant of a generic formal untagged type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Representation aspects of a generic formal parameter are the same as
those of the actual. Representation aspects of a partial view are the same
as those of the full view. A type-related representation item is not allowed
for a descendant of a generic formal untagged type.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>1. The default convention ought to be Ada for any entity not covered by
6.3.1.  The dispatching operations of a type ought to inherit the
convention of the type, for convenient interfacing to other OOP
languages.  (See below for more discussion of this point.)
</P>
<P>-----------------
</P>
<P>2. It is important that Ada allow clean interfaces to other programming
languages.  In particular, it is important that Ada's tagged types can
be used to interface to other OOP languages.
</P>
<P>If an Ada implementation is tightly integrated with another
language, such as C++ or Java, it is nice if an Ada tagged type
can be declared as an extension of a (foreign) type (or class) of the
other language.  Presumably, all of the dispatching operations of this
foreign type would be defined as imported, with the convention of
that other language.  When defining the type extension in Ada, it
would be very inconvenient if every overriding needed
a pragma Convention on it to match that of the inherited operation,
as required by 3.9.2(10).
</P>
<P>Hence, it seems appropriate to define the default calling convention
of an overriding of an inherited dispatching operation to be the same as
that of the corresponding operation on the parent type, rather than
always being convention &quot;Ada&quot; as specified in 6.3.1(3).
</P>
<P>For example:
</P>
<PRE><TT><UL><B>package</B> Java.Graphics <B>is</B>
    <B>type</B> Graphics_Obj <B>is</B> <B>tagged</B> <B>limited</B> <B>private</B>;
    <B>procedure</B> drawString(G : <B>in</B> <B>out</B> Graphics_Obj; S : String);
    <B>pragma</B> Import(Java, drawString);
  ...
<B>end</B> Java.Graphics;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Java.Graphics; <B>use</B> Java.Graphics;
<B>package</B> Flight_Simulator <B>is</B>
    <B>type</B> Simulator_Obj <B>is</B> <B>new</B> Graphics_Obj <B>with</B> <B>private</B>;
    <B>procedure</B> drawString(S : <B>in</B> <B>out</B> Simulator_Obj; S : String);
    -- implicit: pragma Convention(Java, drawString);
 ...
<B>end</B> Flight_Simulator;
</UL></TT></PRE>
<P>The &quot;pragma Convention(Java, ...);&quot; should be implicit when overriding
a dispatching operation with convention Java.  Anything else would be
illegal by 3.9.2(10), and it seems silly to require the programmer
to litter their program with redundant &quot;pragma Convention&quot;s.
</P>
<P>The Note B.1(42) - derived from 13.1 - implies permission of
implementation-defined restrictions of interfacing pragmas. Hence an
implementation will be allowed to reject the attempt to create
&quot;heterogeneous&quot; tagged types, i.e., types having primitive operations
of different, explicitly specified conventions or of explicitly
specified conventions different from the convention of the type.
</P>
<P>2.a. The &quot;Breach of Privacy&quot; Issue
</P>
<P>Presently, the convention of a primitive subprogram can be specified
in the private part of the declaring package. The current rules
require explicit confirmation of this convention for overriding
subprograms and thus constitute a breach of the privacy of the private
part, since the user needs to know about this privately specified
convention in order to make the overriding declaration legal.
</P>
<P>We are very reluctant to mandate Convention pragmas in the visible part
of the package. Although such a rule might be derivable from freezing
rules, it nevertheless could create a compatibility problem for existing
code.
</P>
<P>The proposed new rule of inheriting the convention eases, but does not
eliminate, the breach of privacy, as any explicitly specified convention
will still need to confirm the inherited convention.
</P>
<P>At the implementation level, both the existing and the proposed model
breach the private part, as subtype conformance of overriding with
inherited subprograms includes checking for equality of the convention.
</P>
<P>2.b. Deriving the convention of operations from the type
</P>
<P>Having dispatching operations with the convention of some
other OOP language, while the type is not represented according to the
convention of this other language, will be almost impossible to
implement.  The &quot;normal&quot; case will be that both type and operations
need the convention pragma. In this context, it makes little sense
that the convention of primitive operations defaults to Ada rather
than to the convention of their type. The user will be forced to
repeat the pragma for all the operations of the type.  Considerably
more convenient is a model, in which the default convention of
dispatching operations is inherited from the type, but overridable if
the implementation allows for such mixed conventions.
</P>
<P>Since current rules imply that the convention of a type needs to be
specified for the full view of the type, such dependency creates yet
another breach of privacy in the case of private tagged types. However,
the breach already exists as explained in 2.a. and then to exploit it
for more convenience to the user and a cleaner overall model seems
justified.
</P>
<P>Mandating the specification of the convention for the partial view in
order to avoid the breach of privacy seems too much of an
incompatibility for existing code.
</P>
<P>2.c. The convention of a partial view
</P>
<P>As mentioned previously, the current rules of the standard require that
the convention be specified on the full view. So, what is the convention of
a partial view? It is clear that a partial view and full view must have the
same representation (including convention), since they are just views of the
same entity. However, while this is obvious, it is also not mentioned in the
standard. A statement to this effect needs to be added to 13.1.
</P>
<P>-----------------
</P>
<P>3. Clearly, an implicitly declared dispatching &quot;/=&quot; should not
automatically be illegal.
</P>
<P>The proposed new wording precludes declaring a dispatching operation by
renaming the Intrinsic &quot;/=&quot;, which is good (since there is no real body
associated with &quot;/=&quot;).  It does not make &quot;/=&quot; itself illegal, which is
also good.
</P>
<P>The reason for 6.3.1(4-10) making various subprograms Intrinsic is that
these subprograms don't really exist in machine code.  For example, an
implementation would typically not generate any code for the
implicitly-declared &quot;/=&quot; operator -- instead, it would call the &quot;=&quot;
operator, and then do a &quot;not&quot; operation at the call site.  We don't want
to allow 'Access of such subprograms, because it would introduce an
implementation burden -- the implementation would have to materialize
these subprograms as real machine-code subprograms, which is not
otherwise necessary.
</P>
<P>A similar issue arises with 6.3.1, which says that an inherited
subprogram of a generic formal type with unknown discriminants is of
convention Intrinsic, by default.
</P>
<P>The reason for this rule is obscure enough that it should have been
documented in the AARM:  Consider:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    <B>type</B> Root <B>is</B> <B>tagged</B> <B>null</B> <B>record</B>;
    <B>procedure</B> Proc(X: Root);
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
    <B>type</B> Formal(&lt;&gt;) <B>is</B> <B>new</B> Root <B>with</B> <B>private</B>;
<B>package</B> G <B>is</B>
    ...
<B>end</B> G;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> G <B>is</B>
    ...
    X: Formal := ...;
    ...
    Proc(X); -- This is a dispatching call in Instance, because
             -- the actual type for Formal is class-wide.
    ...
    -- Proc'Access would be illegal here, because it is of
    -- convention Intrinsic, by 6.3.1(8).
<B>end</B> G;
</UL></TT></PRE>
<PRE><TT><UL><B>type</B> Actual <B>is</B> <B>new</B> Root <B>with</B> ...;
<B>procedure</B> Proc(X: Actual);
<B>package</B> Instance <B>is</B> <B>new</B> G(Formal =&gt; Actual'Class);
    -- It is legal to pass in a class-wide actual, because Formal
    -- has unknown discriminants.
</UL></TT></PRE>
<P>Within Instance, all calls to Proc will be dispatching calls, so Proc
doesn't really exist in machine code, so we wish to avoid taking 'Access
of it.  6.3.1(8) applies to those cases where the actual type might be
class-wide, and makes these Intrinsic, thus forbidding 'Access.
</P>
<P>The wording change to 3.9.2(10) shown above means that it is permitted
to have such an inherited subprogram.  If the specification of G contained a
type extension of Formal, then that type's inherited Proc would also have
convention Intrinsic, which would be legal. However, an explicit
overriding of that Proc would be illegal.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0012"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0012 -  Derived access types share the same pool</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00062<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.10</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>NOTE 3.4(31) says, &quot;If the parent type is an access type, then the
parent and the derived type share the same storage pool...&quot;
This is clearly what we want, but I can't seem to prove it from
the real rules (i.e. non-NOTES).
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A derived access type shares its parent's storage pool.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.10(7):   </FONT></B></P>
<UL><P>There are two kinds of access types, <I>access-to-object</I> types, whose values
designate objects, and <I>access-to-subprogram</I> types, whose values designate
subprograms. Associated with an access-to-object type is a <I>storage pool</I>;
several access types may share the same storage pool. A storage pool is an area
of storage used to hold dynamically allocated objects (called <I>pool elements</I>)
created by allocators; storage pools are described further in 13.11,
``Storage Management''.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>There are two kinds of access types, <I>access-to-object</I> types, whose values
designate objects, and <I>access-to-subprogram</I> types, whose values designate
subprograms. Associated with an access-to-object type is a <I>storage pool</I>;
several access types may share the same storage pool. All descendants of an
access type share the same storage pool. A storage pool is an area of
storage used to hold dynamically allocated objects (called <I>pool elements</I>)
created by allocators; storage pools are described further in 13.11,
``Storage Management''.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A derived access type shares its parent's storage pool.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>NOTE 3.4(31) makes the intent clear.
</P>
<P>Furthermore, 13.11.2(16) says, &quot;The execution of a call to an instance of
Unchecked_Deallocation is erroneous if the object was created other than
by an allocator for an access type whose pool is Name'Storage_Pool.&quot;
</P>
<P>Thus, if a derived access type does not have the same pool as its parent,
then the following would be erroneous:
</P>
<PRE><TT><UL><B>type</B> Parent <B>is</B> <B>access</B> Integer;
<B>type</B> Derived <B>is</B> <B>new</B> Parent;
X: Derived := <B>new</B> Integer;
Y: Parent := Parent(X);
<B>procedure</B> Free <B>is</B> <B>new</B>
    Unchecked_Deallocation(Object =&gt; Integer, Name =&gt; Parent);
...
Free(Y);
</UL></TT></PRE>
<P>The above was not erroneous in Ada 83.  This would be a serious upward
incompatibility, which there was no intention to introduce.
</P>
<P>Note that no such upward incompatibility is documented in the AARM.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0013"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0013 -  The first subtype of a type defined by an access[_type]_definition</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00012<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.10</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>3.10(14) says:
</P>
<P><UL>All subtypes of an access-to-subprogram type are constrained. The first
subtype of a type defined by an access_type_definition or an
access_to_object_definition is unconstrained if the designated subtype is an
unconstrained array or discriminated type; otherwise it is constrained.
</UL></P>
<P>However, access_type_definition includes access_to_object_definition.
What is the intent?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The second sentence of 3.10(14) applies to all access-to-object types,
including those defined by access_definitions.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.10(14):   </FONT></B></P>
<UL><P>All subtypes of an access-to-subprogram type are constrained. The first
subtype of a type defined by an <FONT FACE="Arial, Helvetica">access_type_definition</FONT> or an
<FONT FACE="Arial, Helvetica">access_to_object_definition</FONT> is unconstrained if the designated subtype
is an unconstrained array or discriminated type; otherwise it is constrained.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>All subtypes of an access-to-subprogram type are constrained. The first
subtype of a type defined by an <FONT FACE="Arial, Helvetica">access_definition</FONT> or an
<FONT FACE="Arial, Helvetica">access_to_object_definition</FONT> is unconstrained if the designated subtype
is an unconstrained array or discriminated subtype; otherwise it is constrained.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The notion of designated subtype doesn't make sense for
access-to-subprograms.  The intent is that this rule should apply to all
access-to-object types.  Apparently, access_type_definition is a &quot;typo&quot;.
</P>
<P>Another typo was noted in this paragraph. The paragraph says &quot;...if the
designated subtype is an unconstrained array or discriminated type...&quot;, but
this clearly should say &quot;...discriminated {sub}type...&quot;.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0014"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0014 -  Elaboration checks for renamings-as-body</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00064<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.11;  3.11.1;  8.5.4;  13.14</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>3.11(10) indicates that an elaboration check is required only when a
subprogram has an explicit body that is a subprogram_body.  However,
when a renaming declaration is used as a body, it is possible for the
elaboration of the renaming declaration to require the evaluation of a
name, such as X.all, that implies some sort of elaboration check should
be performed.  For example:
</P>
<PRE><TT><UL><B>function</B> F <B>return</B> Integer;
<B>type</B> Pointer_To_Func <B>is</B> <B>access</B> <B>function</B> <B>return</B> Integer;
</UL></TT></PRE>
<PRE><TT><UL>X : Pointer_To_Func := Q'<B>access</B>;  -- Presume Q already elaborated
</UL></TT></PRE>
<PRE><TT><UL>Y : Integer := F;  -- We need some sort of elaboration check
</UL></TT></PRE>
<PRE><TT><UL>....
</UL></TT></PRE>
<PRE><TT><UL>Z : Pointer_To_Func := X;
</UL></TT></PRE>
<PRE><TT><UL><B>function</B> F <B>return</B> Integer <B>renames</B> Z.all;
</UL></TT></PRE>
<P>In the above, clearly we need to wait until the expression &quot;Z.all&quot; is
evaluated before F can be safely called.  However, it is not clear that
any check for this is required by 3.11(10).
</P>
<P>By the way, where is &quot;body&quot; defined?  It presumably includes entry body,
and perhaps renaming-as-body.  However, only the syntactic entity BODY is
defined (in 3.11).  Where is the unbolded term &quot;body&quot; defined?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An elaboration check is performed for a call to a subprogram whose body
is given as a renaming-as-body.  This check fails if the renaming-as-body
has not yet been elaborated.  (As usual, an elaboration check is also
performed for the renamed subprogram, and fails if <I>its</I> body has not yet
been elaborated.)
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.11(10):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
For a call to a (non-protected) subprogram that has an explicit
body, a check is made that the <FONT FACE="Arial, Helvetica">subprogram_body</FONT> is already
elaborated. This check and the evaluations of any actual
parameters of the call are done in an arbitrary order.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
For a call to a (non-protected) subprogram that has an explicit
body, a check is made that the body is already elaborated. This check and
the evaluations of any actual parameters of the call are done in an
arbitrary order.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  3.11.1(1):   </FONT></B></P>
<UL><P>Declarations sometimes come in two parts. A declaration that requires a
second part is said to <I>require completion</I>. The second part is called the
<I>completion</I> of the declaration (and of the entity declared), and is
either another declaration, a body, or a <FONT FACE="Arial, Helvetica">pragma</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Declarations sometimes come in two parts. A declaration that requires a
second part is said to <I>require completion</I>. The second part is called the
<I>completion</I> of the declaration (and of the entity declared), and is
either another declaration, a body, or a <FONT FACE="Arial, Helvetica">pragma</FONT>. A <I>body</I> is a <FONT FACE="Arial, Helvetica">body</FONT>,
an <FONT FACE="Arial, Helvetica">entry_body</FONT>, or a renaming-as-body (see 8.5.4).
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert before  8.5.4(8):   </FONT></B></P>
<UL><P>For a call on a renaming of a dispatching subprogram that is overridden,
if the overriding occurred before the renaming, then the body executed is
that of the overriding declaration, even if the overriding declaration is not
visible at the place of the renaming; otherwise, the inherited or predefined
subprogram is called.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>For a call to a subprogram whose body is given as a renaming-as-body, the
execution of the renaming-as-body is equivalent to the execution of a
<FONT FACE="Arial, Helvetica">subprogram_body</FONT> that simply calls the renamed subprogram with its formal
parameters as the actual parameters and, if it is a function, returns the value
of the call.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.14(3):   </FONT></B></P>
<UL><P>The end of a <FONT FACE="Arial, Helvetica">declarative_part</FONT>, <FONT FACE="Arial, Helvetica">protected_body</FONT>, or a declaration of a
library package or generic library package, causes <I>freezing</I> of each entity
declared within it, except for incomplete types. A noninstance body causes
freezing of each entity declared before it within the same <FONT FACE="Arial, Helvetica">declarative_part</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The end of a <FONT FACE="Arial, Helvetica">declarative_part</FONT>, <FONT FACE="Arial, Helvetica">protected_body</FONT>, or a declaration of a
library package or generic library package, causes <I>freezing</I> of each entity
declared within it, except for incomplete types. A noninstance body other than
a renaming-as-body causes freezing of each entity declared before it within the
same <FONT FACE="Arial, Helvetica">declarative_part</FONT>.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Since the elaboration of a renaming-as-body may evaluate expressions, it
is clearly necessary that this elaboration be performed before calling
the subprogram.  Therefore, an elaboration check should be done on a
subprogram whose body is a renaming-as-body, not just when the body is a
subprogram_body.
</P>
<P>It seems that the right model for renaming-as-body that occurs after the
subprogram is frozen should be that of a wrapper subprogram, with its own
elaboration flag.
</P>
<P>Taken together, these rules imply that when calling a subprogram whose
body is a renaming-as-body, a check will be made that the renaming-as-body
has been elaborated, and also that the body of the renamed subprogram has
been elaborated.  Furthermore, if the renamed subprogram is in turn
completed by <I>another</I> renaming-as-body, the body of that third subprogram
will also be checked; the rule is transitive.
</P>
<P>See 8652/0027 (AI-00135) for a discussion of circularities involving
renamings-as-body.
</P>
<P>This issue also adds the missing definition of the semantic term &quot;body&quot;. This
change makes a renaming-as-body a body. However, doing so triggers the freezing
rule 13.14(3): &quot;A noninstance body other than a renaming-as-body causes
freezing of each entity declared before it within the same declarative_part.&quot;
It clearly was the intent of the designers of the language that
renaming-as-body not freeze (otherwise the second sentence of 8.5.4(5) could
never be true), and existing compilers do not freeze when a renaming-as-body
is encountered. We do not want to change this behavior, so we add an exception
to 13.14(3).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0015"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0015 -  Float_Type'Small</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00093<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 4.1.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Paragraph 4.1.4(12) says:
</P>
<P><UL>An implementation may provide implementation-defined attributes; the
identifier for an implementation-defined attribute shall differ from
those of the language-defined attributes.
</UL></P>
<P>AARM J(1.d) lists several Ada 83 floating-point attributes that have been
removed from the language, including 'Small; AARM J(1.h), however, says that
&quot;Implementations can continue to support the above features for upward
compatibility&quot;.
</P>
<P>Since 'Small is a language-defined attribute for fixed-point types,
4.1.4(12) implies that an implementation must not provide a 'Small
attribute for floating-point types.  This clearly contradicts the intent
of J(1).
</P>
<P>May an implementation support the 'Small attribute for floating-point
types?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An implementation may support an implementation-defined attribute Small
for floating point types.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.1.4(12):   </FONT></B></P>
<UL><P>An implementation may provide implementation-defined attributes; the
<FONT FACE="Arial, Helvetica">identifier</FONT> for an implementation-defined attribute shall differ from
those of the language-defined attributes.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An implementation may provide implementation-defined attributes; the
<FONT FACE="Arial, Helvetica">identifier</FONT> for an implementation-defined attribute shall differ from
those of the language-defined attributes unless supplied for
compatibility with a previous edition of this International Standard.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is that implementations be allowed to support all Ada 83
attributes, for upward compatibility.  Thus, it is important that they
be allowed to support the Small attribute on floating point types.
Therefore, this resolution makes a specific exception to the rule in 4.1.4(12).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0016"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0016 -  Equality for composite types</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00123<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 4.5.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The following language-defined types are private, and have an explicitly
defined primitive &quot;=&quot; operator:
</P>
<P><UL>System.Address
</UL></P>
<P><UL>Ada.Strings.Maps.Character_Set
</UL></P>
<P><UL>Ada.Strings.Bounded.Generic_Bounded_Length.Bounded_String
</UL></P>
<P><UL>Ada.Strings.Unbounded.Unbounded_String
</UL></P>
<P><UL>Ada.Strings.Wide_Maps.Wide_Character_Set
</UL></P>
<P><UL>Ada.Task_Identification.Task_ID
</UL></P>
<P>This would seem to imply that the composability of these &quot;=&quot; operators
depends on whether the implementation chooses to implement them as
tagged types, by 4.5.2(14-15):
</P>
<P><UL>For a type extension, predefined equality is defined in terms of the
primitive (possibly user-defined) equals operator of the parent type and of
any tagged components of the extension part, and predefined equality for any
other components not inherited from the parent type.
</UL></P>
<P><UL>For a private type, if its full type is tagged, predefined equality is
defined in terms of the primitive equals operator of the full type; if the
full type is untagged, predefined equality for the private type is that of
its full type.
</UL></P>
<P>and by 4.5.2(21-24):
</P>
<P><UL>Given the above definition of matching components, the result of the
predefined equals operator for composite types (other than for those
composite types covered earlier) is defined as follows:
</UL></P>
<P><UL><UL>If there are no components, the result is defined to be True;
</UL></UL></P>
<P><UL><UL>If there are unmatched components, the result is defined to be
False;
</UL></UL></P>
<P><UL><UL>Otherwise, the result is defined in terms of the primitive equals
operator for any matching tagged components, and the predefined
equals for any matching untagged components.
</UL></UL></P>
<P>This would cause portability problems.
</P>
<P>Also, in the above definition, what does &quot;in terms of&quot; mean?  For a
composite type, if some parts have an &quot;=&quot; with side effects, does the
language define whether all of these side effects happen, and in what
order?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The primitive equality operators of a language-defined type compose
properly (i.e., do not &quot;reemerge&quot;), when the type is used as a component
type, or a generic actual type.
</P>
<P>For any composite type, the order in which &quot;=&quot; is called for components
is not defined by the language. Furthermore, if the result can be
determined before calling &quot;=&quot; on some components, the language does not
define whether &quot;=&quot; is called on those components.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  4.5.2(24):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
Otherwise, the result is defined in terms of the primitive equals
operator for any matching tagged components, and the predefined
equals for any matching untagged components.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>For any composite type, the order in which &quot;=&quot; is called for components is
unspecified. Furthermore, if the result can be determined
before calling &quot;=&quot; on some components, it is unspecified whether
&quot;=&quot; is called on those components.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  4.5.2(32):   </FONT></B></P>
<UL><P>A membership test using <B>not in</B> gives the complementary result to the
corresponding membership test using <B>in</B>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P><I><FONT SIZE=-2>Implementation Requirements</FONT></I><BR>
For all nonlimited types declared in language-defined packages, the &quot;=&quot;
and &quot;/=&quot; operators of the type shall behave as if they were the predefined
equality operators for the purposes of the equality of composite types and
generic formal types.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Composability of equality for a type T means three things:
</P>
<P><UL>1. If a composite type has a component of type T with a user-defined
equality operator, then the predefined equality of the composite
type calls the user-defined equality operator of type T (for that
component).
</UL></P>
<P><UL>2. If an actual type T for a generic formal type has a user-defined
equality operator, then the predefined equality on the generic
formal type calls the user-defined equality operator of type T.
</UL></P>
<P><UL>3. If a parent type T has a user-defined equality operator, then the
predefined equality of a type extension of T calls the
user-defined equality on T (for the parent part), in addition to
comparing the extension parts.
</UL></P>
<P>Non-composability means that the predefined equality is called for T,
despite the fact that T has a user-defined equality operator. Of
course, if there is no user-defined equality, then equality always
composes properly.
</P>
<P>Item 3 is irrelevant here, since none of the types in question is
(visibly) tagged.
</P>
<P>For a private type, if the underlying type is tagged, or if there is no
user-defined equality, then equality composes. Otherwise, it does not.
(Here, &quot;underlying type&quot; means the full type, or if that comes from a
private type, then the underlying type of <I>that</I> type, and so on.)
</P>
<P>However, for the private types mentioned in the question, the standard does
not specify whether the underlying type is tagged, nor whether the
equality operator is truly user-defined (as opposed to just being the
normal bit-wise equality).
</P>
<P>It is important that the composability of &quot;=&quot; for these types be defined
by the language. We choose to make them composable. An implementation
can achieve this by making the full type tagged. Alternatively, the
implementation could simply use the predefined &quot;=&quot; for these types.
(Alternatively, an implementation could treat these types specially,
making them untagged, but with composable equality. However, this would
add some complexity to the compiler.)
</P>
<P>Here is an analysis of implementation concerns for each type in
question:
</P>
<P><UL>- System.Address: The intent is for this type to directly represent
a hardware address. Therefore, it is probably not feasible to
implement it as a tagged type. The simplest implementation of
equality of Addresses is thus the normal bit-wise equality. This
is what most users would expect, anyway.
</UL></P>
<P><UL><UL>On certain segmented architectures, it is possible for two
different addresses to point to the same location. The same thing
can happen due to memory mapping, on many machines. Such
addresses will typically compare unequal, despite the fact that
they point to the same location.
</UL></UL></P>
<P><UL>- Ada.Strings.Maps.Character_Set: A typical implementation will use
an array of Booleans, so bit-wise equality will be used, so it
will compose.
</UL></P>
<P><UL>- Ada.Strings.Bounded.Generic_Bounded_Length.Bounded_String: Two
reasonable implementations are: (1) Set the unused characters to
some particular character, and use bit-wise equality, and (2) use
a tagged type with a user-defined equality. Either way, equality
will compose. This is, admittedly, a slight implementation
burden, because it rules out an untagged record with user-defined
equality.
</UL></P>
<P><UL>- Ada.Strings.Unbounded.Unbounded_String: A tagged (controlled) type
will normally be necessary anyway, for storage reclamation. In a
garbage-collected implementation, a tagged type is not strictly
necessary, but we choose to require composability anyway.
</UL></P>
<P><UL>- Ada.Strings.Wide_Maps.Wide_Character_Set: Some sort of data
structure built out of access types is necessary anyway, so the
extra overhead of composability is not a serious problem; the
implementation can simply make the full type tagged.
</UL></P>
<P><UL>- Ada.Task_Identification.Task_ID: This will typically be a
pointer-to-TCB of some sort (access-to-TCB, or
index-into-table-of-TCB's). In any case, bit-wise equality will
work, so equality will compose.
</UL></P>
<P>As to the second question, the standard clearly does not define any order of
calling &quot;=&quot; on components, nor does it say whether the results are
combined with &quot;and&quot; or &quot;and then&quot;. Equality operators with side effects
are questionable in any case, so we allow implementations freedom to do
what is most convenient and/or most efficient. Consider equality of a
variant record: The implementation might first check that the
discriminants are equal, and if not, skip the component-by-component
comparison. Alternatively, the implementation might first compare the
common elements, and <I>then</I> check the discriminants. A third
possibility is to first compare some portions with a bit-wise equality,
and then (conditionally) call user-defined equality operators on the
other components. All of these implementations are valid.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0017"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0017 -  Definiteness and type derivation</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00184<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 4.6;  8.5.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The definiteness of a type is not preserved by type derivation.  A type with
defaulted discriminants may be derived from a type without defaulted
discriminants and vice-versa.
</P>
<P>This makes it possible to rename a component of a record that later disappears
due to an assignment to the enclosing object, as shown in the following
examples:
</P>
<P>1 - An example where the parent type is indefinite and the derived type is
definite:
</P>
<PRE><TT><UL><B>type</B> T1 (D1 : Boolean) <B>is</B>
   <B>record</B>
      <B>case</B> D1 <B>is</B>
         <B>when</B> False =&gt;
            C1 : Integer;
         <B>when</B> True =&gt;
            C2 : Float;
         <B>end</B> <B>case</B>;
      <B>end</B> <B>record</B>;
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
   <B>type</B> F <B>is</B> <B>new</B> T1;
   X : <B>in</B> <B>out</B> F;
<B>package</B> G <B>is</B>
   C1_Ren : Integer <B>renames</B> X.C1;
<B>end</B> G;
</UL></TT></PRE>
<PRE><TT><UL><B>type</B> T2 (D2 : Boolean := True) <B>is</B> <B>new</B> T1 (D1 =&gt; D2);
</UL></TT></PRE>
<PRE><TT><UL>Y : T2;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> I <B>is</B> <B>new</B> G (T2, Y);
</UL></TT></PRE>
<PRE><TT><UL>Y := (D1 =&gt; True, C2 =&gt; 3.0); -- Oops!  What happened to I.C1_Ren
</UL></TT></PRE>
<P>The declaration of C1_Ren in the generic G is legal as per 8.5.1(5),
because the formal type F is indefinite.  But when G is instantiated with type
T2, the actual type is definite, so now we have renamed a component that may
disappear by assignment to the variable Y.  Note that the declaration of
C1_Ren might be in the body of G, so we cannot avoid this problem by
rechecking 8.5.1(5) on the instantiation.
</P>
<P>2 - An example where the parent type is definite and the derived type is
indefinite:
</P>
<PRE><TT><UL><B>type</B> Definite_Parent (D1 : Integer := 6) <B>is</B>
   <B>record</B>
      F : String (1 .. D1);
   <B>end</B> <B>record</B>;
</UL></TT></PRE>
<PRE><TT><UL><B>type</B> Indefinite_Child (D2 : Integer) <B>is</B> <B>new</B> Definite_Parent (D1 =&gt; D2);
</UL></TT></PRE>
<PRE><TT><UL>Y : Definite_Parent;
</UL></TT></PRE>
<PRE><TT><UL><B>procedure</B> P (X : <B>in</B> <B>out</B> Indefinite_Child) <B>is</B>
   C : Character <B>renames</B> X.F (3);
<B>begin</B>
   X := (0, &quot;&quot;);
   -- X.F (3) has disappeared!
<B>end</B>;
<B>begin</B>
P (Indefinite_Child (Y));
</UL></TT></PRE>
<P>Assume that the implementation chooses to pass X by reference.  Then,
6.4.1(10) says that there is an implicit view conversion to Indefinite_Child,
and the formal parameter X then denotes the result of this view conversion.
The result of the explicit view conversion is unconstrained, and the result
of the implicit view conversion is also unconstrained, hence X is
unconstrained, which violates the language design principle of the NOTE in
3.7(28).
</P>
<P>One of the unpleasant consequences of this violation is that the assignment to
X doesn't raise an exception, and after the execution of this assignment C
denotes a non-existent component.
</P>
<P>Note that if the implementation chooses to pass by copy, then there is an
implicit value conversion -- see 6.4.1(11).  So in that case, there's no
problem.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The legality rules about object renaming are checked in the private part of an
instance.  In a generic body, they are checked in an assume-the-worst manner:
it is illegal to rename a component that depends on a discriminant of a
variable whose nominal subtype is an untagged indefinite generic formal
derived type (or a descendant of such a type) unless the variable is aliased.
</P>
<P>A view conversion to an indefinite object is constrained.
</P>
<P>For a conversion of an object name to a tagged type to be a view conversion,
the object's nominal subtype has to be tagged.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.6(5):   </FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">type_conversion</FONT> whose operand is the <FONT FACE="Arial, Helvetica">name</FONT> of an object is called a
<I>view conversion</I> if its target type is tagged, or if it appears as an actual
parameter of mode <B>out</B> or <B>in out</B>; other <FONT FACE="Arial, Helvetica">type_conversion</FONT>s are
called <I>value conversions</I>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">type_conversion</FONT> whose operand is the <FONT FACE="Arial, Helvetica">name</FONT> of an object is called a
<I>view conversion</I> if both its target type and operand type are tagged, or
if it appears as an actual parameter of mode <B>out</B> or <B>in out</B>; other
<FONT FACE="Arial, Helvetica">type_conversion</FONT>s are called <I>value conversions</I>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  4.6(54):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
If the target type is composite, the bounds or discriminants (if
any) of the view are as defined above for a value conversion;
each nondiscriminant component of the view denotes the matching
component of the operand object; the subtype of the view is
constrained if either the target subtype or the operand object is
constrained, or if the operand type is a descendant of the target
type, and has discriminants that were not inherited from the
target type;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
If the target type is composite, the bounds or discriminants (if
any) of the view are as defined above for a value conversion;
each nondiscriminant component of the view denotes the matching
component of the operand object; the subtype of the view is
constrained if either the target subtype or the operand object is
constrained, or if the target subtype is indefinite, or if the operand type is
a descendant of the target type and has discriminants that were not
inherited from the target type;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.5.1(5):   </FONT></B></P>
<UL><P>The renamed entity shall not be a subcomponent that depends on
discriminants of a variable whose nominal subtype is unconstrained, unless
this subtype is indefinite, or the variable is aliased. A <FONT FACE="Arial, Helvetica">slice</FONT> of an array
shall not be renamed if this restriction disallows renaming of the array.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The renamed entity shall not be a subcomponent that depends on
discriminants of a variable whose nominal subtype is unconstrained, unless
this subtype is indefinite, or the variable is aliased. A <FONT FACE="Arial, Helvetica">slice</FONT> of an array
shall not be renamed if this restriction disallows renaming of the array.
In addition to the places where Legality Rules normally apply, these rules
apply also in the private part of an instance of a generic unit. These rules
also apply for a renaming that appears in the body of a generic unit, with
the additional requirement that even if the nominal subtype of the variable is
indefinite, its type shall not be a descendant of an untagged generic
formal derived type.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The fix for example 1 is to forbid the renaming: even though the formal type
looks indefinite, it is possible for the actual type to be definite.  Note that
the manual already covers the case where C1_Ren is declared in the visible
part of the generic unit, because legality rules are checked in the instance
(12.3(11)).  We are extending the legality rules for object renaming to
apply in the private part of the instance, and we are assuming the worst in
the body.
</P>
<P>To fix example 2, we could forbid a view conversion that obtains an indefinite
view of an object whose nominal subtype is definite.  However, such a view
conversion was legal in Ada 83, so this would be an incompatibility.  It seems
better to mandate a check on the assignment to X: it is very surprising that
this check is not there in the first place.
</P>
<P>Also consider the following example:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
   <B>pragma</B> Elaborate_Body;
   <B>type</B> T (D : Integer) <B>is</B> <B>private</B>;
<B>private</B>
   <B>type</B> T (D : Integer) <B>is</B> <B>tagged</B>
      <B>record</B>
         C : String (1 .. D);
      <B>end</B> <B>record</B>;
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> P;
<B>package</B> Q <B>is</B>
   <B>type</B> NT (ND : Integer := 3) <B>is</B> <B>new</B> T (ND);
   X : NT;
   Y : NT (0);
<B>end</B> Q
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Q;
<B>package</B> <B>body</B> P <B>is</B>
   C_Ren : Character <B>renames</B> T (Q.X).C (2);
<B>begin</B>
   Q.X := Q.Y; -- Houston, we have a problem!
<B>end</B> P;
</UL></TT></PRE>
<P>This is similar to example 2 above, except that here we don't use a view
conversion to change the discriminant of Q.X.  In this case the trouble
comes from the view conversion T (Q.X) in the declaration of C_Ren.  As
long as all the types involved are tagged, renaming a component of a
view conversion works fine, because tagged types don't have defaulted
discriminants.  But here we go through an untagged type to change the
discriminants.  It is clear that the conversion T (Q.X) should not be
considered a view conversion.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0018"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0018 -  Full conformance of expressions with attributes</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00175<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 6.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Is Integer'Succ fully conformant with Integer'Pred? (No.)
</P>
<P>From 6.3.1(19-22), it would appear so:  both attribute_references
have the syntactic construction
</P>
<P><UL>prefix ' attribute_designator := name ' identifier
</UL></P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For two attribute_references to fully conform, the attribute_designator
must be the same.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  6.3.1(21):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
each <FONT FACE="Arial, Helvetica">direct_name</FONT>, <FONT FACE="Arial, Helvetica">character_literal</FONT>, and <FONT FACE="Arial, Helvetica">selector_name</FONT>
that is not part of the <FONT FACE="Arial, Helvetica">prefix</FONT> of an expanded name in one denotes the
same declaration as the corresponding <FONT FACE="Arial, Helvetica">direct_name</FONT>, <FONT FACE="Arial, Helvetica">character_literal</FONT>,
or <FONT FACE="Arial, Helvetica">selector_name</FONT> in the other; and</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
each <FONT FACE="Arial, Helvetica">attribute_designator</FONT> in one must be the same as the
corresponding <FONT FACE="Arial, Helvetica">attribute_designator</FONT> in the other; and</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It would be ludicrous to treat two different attributes to be fully
conformant. None of the reasons for conformance checking would be
enforced if this were true. Thus, the standard's failure to require this can
only be categorized as an oversight.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0019"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0019 -  Delayed declaration of inherited primitive subprograms</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00033<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 7.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Is the rule given in 7.3.1(6) intended to apply to cases where
a derived type is declared outside the declarative region in
which its parent type is immediately declared?  (No.)
</P>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>package</B> <B>body</B> R <B>is</B>
</UL></TT></PRE>
<PRE><TT><UL>   <B>package</B> P <B>is</B>
      <B>type</B> Pt <B>is</B> ...;
   <B>private</B>
      <B>procedure</B> Op (X : Pt);
   <B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> T <B>is</B> <B>new</B> P.Pt;
      -- procedure Op (X : T); is inherited here but not yet declared
</UL></TT></PRE>
<PRE><TT><UL>   <B>package</B> <B>body</B> P <B>is</B>
      -- procedure Op (X : T) is declared here, according to
      -- 7.3.1(6), because the corresponding declaration for Pt
      -- is visible at this point and the body of P is still within
      -- the immediate scope of T. It is somewhat strange, however,
      -- that the subprogram does not get declared immediately
      -- within the same declarative region as T.
      -- Is this the intent?  (No.)
   <B>begin</B>
      Op(T'(...)); -- Legal?  (No.)
   <B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>end</B> R;
</UL></TT></PRE>
<P>Also, are the rules of 7.3.1(3) and 7.3.1(4) regarding the
availability of additional characteristics for composite types
and derived types intended to apply when such types are declared
outside the declarative region in which a component type or
parent type is immediately declared?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>7.3.1 describes places where additional characteristics of a type become
revealed. These rules apply only <I>immediately</I> within the declarative
region in which the type is declared.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.3.1(3):   </FONT></B></P>
<UL><P>For a composite type, the characteristics (see 7.3) of the type are
determined in part by the characteristics of its component types. At the
place where the composite type is declared, the only characteristics of
component types used are those characteristics visible at that place. If
later within the immediate scope of the composite type additional
characteristics become visible for a component type, then any corresponding
characteristics become visible for the composite type. Any additional
predefined operators are implicitly declared at that place.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For a composite type, the characteristics (see 7.3) of the type are
determined in part by the characteristics of its component types. At the place
where the composite type is declared, the only characteristics of component
types used are those characteristics visible at that place. If later immediately
within the declarative region in which the composite type is declared additional
characteristics become visible for a component type, then any corresponding
characteristics become visible for the composite type. Any additional predefined
operators are implicitly declared at that place.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.3.1(4):   </FONT></B></P>
<UL><P>The corresponding rule applies to a type defined by a
<FONT FACE="Arial, Helvetica">derived_type_definition</FONT>, if there is a place within its immediate scope
where additional characteristics of its parent type become visible.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The corresponding rule applies to a type defined by a
<FONT FACE="Arial, Helvetica">derived_type_definition</FONT>, if there is a place immediately within the
declarative region in which the type is declared where additional
characteristics of its parent type become visible.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.3.1(5):   </FONT></B></P>
<UL><P>For example, an array type whose component type is limited private
becomes nonlimited if the full view of the component type is nonlimited and
visible at some later place within the immediate scope of the array type. In
such a case, the predefined &quot;=&quot; operator is implicitly declared at that
place, and assignment is allowed after that place.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For example, an array type whose component type is limited private
becomes nonlimited if the full view of the component type is nonlimited and
visible at some later place immediately within the declarative region in which
the array type is declared. In such a case, the predefined &quot;=&quot; operator is
implicitly declared at that place, and assignment is allowed after that place.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.3.1(6):   </FONT></B></P>
<UL><P>Inherited primitive subprograms follow a different rule. For a
<FONT FACE="Arial, Helvetica">derived_type_definition</FONT>, each inherited primitive subprogram is implicitly
declared at the earliest place, if any, within the immediate scope of the
<FONT FACE="Arial, Helvetica">type_declaration</FONT>, but after the <FONT FACE="Arial, Helvetica">type_declaration</FONT>, where the
corresponding declaration from the parent is visible. If there is no such place,
then the inherited subprogram is not declared at all. An inherited subprogram
that is not declared at all cannot be named in a call and cannot be overridden,
but for a tagged type, it is possible to dispatch to it.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Inherited primitive subprograms follow a different rule. For a
<FONT FACE="Arial, Helvetica">derived_type_definition</FONT>, each inherited primitive subprogram is implicitly
declared at the earliest place, if any, immediately within the declarative
region in which the <FONT FACE="Arial, Helvetica">type_declaration</FONT> occurs, but after the
<FONT FACE="Arial, Helvetica">type_declaration</FONT>, where the corresponding declaration from the parent is
visible. If there is no such place, then the inherited subprogram is not
declared at all. An inherited subprogram that is not declared at all cannot
be named in a call and cannot be overridden, but for a tagged type it is
possible to dispatch to it.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The wording of 7.3.1 was inherited from the Ada 83 standard's subsection 7.4.2,
but by stating the rules in terms of the immediate scope of the type this
inadvertently included all nested scopes, which was not intended.
</P>
<P>Consider:
</P>
<PRE><TT><UL><B>package</B> Outer <B>is</B>
    <B>package</B> Inner <B>is</B>
        <B>type</B> Inner_Type <B>is</B> <B>private</B>;
    <B>private</B>
        <B>type</B> Inner_Type <B>is</B> <B>new</B> Boolean;
    <B>end</B> Inner;
</UL></TT></PRE>
<PRE><TT><UL>    <B>type</B> Outer_Type <B>is</B> <B>array</B>(Natural <B>range</B> &lt;&gt;) <B>of</B> Inner.Inner_Type;
<B>end</B> Outer;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> Outer <B>is</B>
    <B>package</B> <B>body</B> Inner <B>is</B>
        ...
        -- At this point, we can see that Inner_Type is a Boolean type.
        -- So does Outer_Type have an &quot;and&quot; operator here?  (No.)
    <B>end</B> Inner;
<B>end</B> Outer;
</UL></TT></PRE>
<P>The wording of 7.3.1(3) would seem to imply that an &quot;and&quot; operator is
implicitly declared for type Outer_Type at the beginning of the body of
Inner, since this is within the immediate scope of Outer_Type. However,
in Ada 83, such an &quot;and&quot; operator was not implicitly declared -- such an
operator could only be declared <I>immediately</I> within the declarative
region of Outer_Type -- not in some nested Inner package.
</P>
<P>This language change was not intended. Furthermore, the principle that
implicit declarations of operators (or other additional characteristics)
can only be revealed <I>immediately</I> within the declaration region of the
outer type should be preserved, even in the case of new language
features, such as child packages. Therefore, 7.3.1(3,4,5,6) are changed
accordingly.
</P>
<P>The Ada 83 standard prefaced paragraph 7.4.2(6) by saying, &quot;If the composite
type is itself declared within the package that declares the private type&quot;,
which avoided the problems introduced by 7.3.1(3,4,6). In attempting to be
more general and include derived types as well as composite types, plus
handle the case of child units (which are not &quot;within&quot; their parent
package but are &quot;within the declarative region of&quot; their parent), the
restriction imposed by the Ada 83 preface was unintentionally lost. Note
that the AARM does not list this as a &quot;Change from Ada 83&quot;, which is
further evidence that this change was not intended. Also, paragraph
7.3.1(7.b) of the AARM makes it clear that these rules were only meant
to pertain to types declared within the same declarative region as the
component type or parent type providing the additional operations.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0020"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0020 -  Classification of language-defined packages</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00126<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 7.6;  A.5.1;  G.1.1;  G.1.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>None of the language-defined packages has a pragma Remote_Types.
This makes distributed programming less convenient, because the
types declared in these packages cannot be transported across
partitions (unless, of course, the package has a pragma Pure).
Should some of the language-defined packages be remote types
packages?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The following language-defined packages are declared Pure:
</P>
<P><UL>Ada.Numerics.Complex_Elementary_Functions   G.1.2(9)
</UL></P>
<P><UL>Ada.Numerics.Complex_Types   G.1.1(25)
</UL></P>
<P><UL>Ada.Numerics.Elementary_Functions   A.5.1(9)
</UL></P>
<P>The other nongeneric equivalents defined in these sections are also
declared Pure, if they exist.
</P>
<P>The following language-defined package is a remote types package:
</P>
<P><UL>Ada.Finalization   7.6(4)
</UL></P>
<P>For each language-defined generic package that is declared Pure (or
preelaborated), the private part must not contain anything that would
prevent instances from being declared Pure (preelaborated,
respectively).
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.6(4):   </FONT></B></P>
<UL><UL><PRE><TT><B>package</B> Ada.Finalization <B>is</B>
    <B>pragma</B> Preelaborate(Finalization);</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>package</B> Ada.Finalization <B>is</B>
    <B>pragma</B> Preelaborate(Finalization);
    <B>pragma</B> Remote_Types(Finalization);</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.5.1(9):   </FONT></B></P>
<UL><P>The library package Numerics.Elementary_Functions defines the same subprograms
as Numerics.Generic_Elementary_Functions, except that the predefined type Float
is systematically substituted for Float_Type'Base throughout. Nongeneric
equivalents of Numerics.Generic_Elementary_Functions for each of the other
predefined floating point types are defined similarly, with the names
Numerics.Short_Elementary_Functions, Numerics.Long_Elementary_Functions, etc.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The library package Numerics.Elementary_Functions is declared pure and defines
the same subprograms as Numerics.Generic_Elementary_Functions, except that the
predefined type Float is systematically substituted for Float_Type'Base
throughout. Nongeneric equivalents of Numerics.Generic_Elementary_Functions for
each of the other predefined floating point types are defined similarly, with
the names Numerics.Short_Elementary_Functions,
Numerics.Long_Elementary_Functions, etc.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  G.1.1(25):   </FONT></B></P>
<UL><P>The library package Numerics.Complex_Types defines the same types, constants,
and subprograms as Numerics.Generic_Complex_Types, except that the predefined
type Float is systematically substituted for Real'Base throughout. Nongeneric
equivalents of Numerics.Generic_Complex_Types for each of the other predefined
floating point types are defined similarly, with the names
Numerics.Short_Complex_Types, Numerics.Long_Complex_Types, etc.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The library package Numerics.Complex_Types is declared pure and defines the
same types, constants, and subprograms as Numerics.Generic_Complex_Types,
except that the predefined type Float is systematically substituted for
Real'Base throughout.
Nongeneric equivalents of Numerics.Generic_Complex_Types for each of the other
predefined floating point types are defined similarly, with the names
Numerics.Short_Complex_Types, Numerics.Long_Complex_Types, etc.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  G.1.2(9):   </FONT></B></P>
<UL><P>The library package Numerics.Complex_Elementary_Functions defines the same
subprograms as Numerics.Generic_Complex_Elementary_Functions, except that the
predefined type Float is systematically substituted for Real'Base, and the
Complex and Imaginary types exported by Numerics.Complex_Types are
systematically substituted for Complex and Imaginary, throughout. Nongeneric
equivalents of Numerics.Generic_Complex_Elementary_Functions corresponding to
each of the other predefined floating point types are defined similarly, with
the names Numerics.Short_Complex_Elementary_Functions,
Numerics.Long_Complex_Elementary_Functions, etc.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The library package Numerics.Complex_Elementary_Functions is declared pure and
defines the same subprograms as Numerics.Generic_Complex_Elementary_Functions,
except that the predefined type Float is systematically substituted for
Real'Base, and the Complex and Imaginary types exported by
Numerics.Complex_Types are systematically substituted for Complex and Imaginary,
throughout. Nongeneric equivalents of
Numerics.Generic_Complex_Elementary_Functions corresponding to each of the other
predefined floating point types are defined similarly, with the names
Numerics.Short_Complex_Elementary_Functions,
Numerics.Long_Complex_Elementary_Functions, etc.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Ada.Numerics has three children that are instances of declared-pure
generic packages.  The intent is that these instances also be declared
pure, even though 8652/0034 (AI-00041) says that this does not happen by
default.
</P>
<P>Now, it might seem that many language-defined packages ought to be
remote types packages.  However, it turns out that this makes sense for
very few language-defined packages, and is important for only one:
Finalization.  Detailed analysis follows.
</P>
<P>The following is a list of all the language-defined library units.  On
the right, &quot;Pure&quot; or &quot;Preelaborate&quot; are the pragmas provided by the standard
for each package.  (The three instances mentioned above are also shown as
&quot;Pure&quot;.)  For each package, &quot;Yes&quot; means it could reasonably be a remote
types package; &quot;No&quot; means it should not.  If neither &quot;Yes&quot; nor &quot;No&quot; is
shown, that means &quot;No&quot;, and the reason is that the type(s) declared in
that package are inappropriate for transporting across partitions.  This
is true of the I/O packages, for example -- we don't want to require
transporting files across partitions.
</P>
<P>There is no point in making a declared-pure package into a remote types
package, so all the ones marked &quot;Pure&quot; are &quot;No&quot; by default.
</P>
<P>It makes sense for a package to have both pragmas Preelaborate and
Remote_Types.
</P>
<P>&quot;No -- access type T&quot; means, &quot;We can't make it a remote types package, because
it contains an access type, and we don't want that access type to be a
remote access type.&quot;
</P>
<P>&quot;No -- depends on X&quot; means, &quot;We can't make it a remote types package, because
it depends on X, and we have decided X should not be pure, shared passive,
or remote types.&quot;  See E.2.2(6).
</P>
<P>Note that Ada.Calendar and Ada.Real_Time should not be remote types packages,
because we wish to allow implementations to choose a different
representation for the time-related types on different partitions.  For
example, type Calendar.Time on one partition might use a different
&quot;epoch&quot; than on another partition.  The types involved are:
Calendar.Time, Real_Time.Time, Real_Time.Time_Span, and
Real_Time.Seconds_Count.  Thus, in order to pass time values across
partitions, the programmer will have to define an application-specific
time type, and translate to that.
</P>
<P>Note that Ada.Exceptions is listed as &quot;No&quot;, because it contains an
access type that should not be a remote access type.  It was one of the
cases mentioned in the comments that prompted this issue.  This is
unfortunate; one would like to transport values of types Exception_Id
and Exception_Occurrence.
</P>
<P>Note that Ada.Task_Identification should not be a remote types package.  If it
were, then one could pass a Task_ID across partitions, and then do things
like Abort_Task on that Task_ID on the &quot;wrong&quot; partition.  This would
require the tasking run-time system to know about distribution, which
was never intended; alternatively, it would require us to declare such
cases erroneous, which seems pointlessly error prone.  Note also that
this package cannot be declared Pure or Shared_Passive, because Task_ID
is likely to be implemented using access types.
</P>
<P>Note that the Discrete_Random and Float_Random packages are not made
remote types packages.  It makes no sense to copy the generators, since
they are supposed to have reference semantics.
</P>
<P>This leaves Finalization, Characters.Handling, Command_Line, and
Interfaces.COBOL as potential candidates for being remote types
packages.  Of these, the only significant additional functionality is
for Finalization.  Therefore, we choose to make Finalization a remote
types package, and leave the other three as specified in the current standard.
(It seems silly, for example, to make Command_Line a remote types package, so
that values of type Exit_Status can be transported, when Strings.Unbounded is
not made a remote types package, so that values of type Unbounded_String cannot
be transported; the latter would be far more useful, if it were possible.)
</P>
<P>Analysis of each language-defined library unit follows:
</P>
<PRE><TT><UL>Standard   A.1(4)                                            Pure
Ada   A.2(2)                                                 Pure
Ada.Asynchronous_Task_Control   D.11(3)
    No -- no need to make it a remote types package.
Ada.Calendar   9.6(10)
Ada.Characters   A.3.1(2)                                    Pure
Ada.Characters.Handling   A.3.2(2)                           Preelaborate
    Yes.
Ada.Characters.Latin_1   A.3.3(3)                            Pure
Ada.Command_Line   A.15(3)                                   Preelaborate
    Yes.
Ada.Decimal   F.2(2)                                         Pure
Ada.Direct_IO   A.8.4(2), A.9(3)
Ada.Dynamic_Priorities   D.5(3)
    No -- no need to make it a remote types package.
Ada.Exceptions   11.4.1(2)
    No -- access type Exception_Occurrence_Access.
Ada.Finalization   7.6(4)                                    Preelaborate
    Yes.
Ada.Float_Text_IO   A.10.9(32)
Ada.Float_Wide_Text_IO   A.11(3)
Ada.Integer_Text_IO   A.10.8(20)
Ada.Integer_Wide_Text_IO   A.11(3)
Ada.Interrupts   C.3.2(2)
    No -- access type Parameterless_Handler.
Ada.Interrupts.Names   C.3.2(12)
    No -- depends on Ada.Interrupts.
Ada.IO_Exceptions   A.13(3)                                  Pure
Ada.Numerics   A.5(3)                                        Pure
Ada.Numerics.Complex_Elementary_Functions   G.1.2(9)         Pure
Ada.Numerics.Complex_Types   G.1.1(25)                       Pure
Ada.Numerics.Discrete_Random   A.5.2(17)
    No -- the generator parameter is supposed to have reference semantics.
Ada.Numerics.Elementary_Functions   A.5.1(9)                 Pure
Ada.Numerics.Float_Random   A.5.2(5)
    No -- the generator parameter is supposed to have reference semantics.
Ada.Numerics.Generic_Complex_Elementary_Functions   G.1.2(2) Pure
Ada.Numerics.Generic_Complex_Types   G.1.1(2)                Pure
Ada.Numerics.Generic_Elementary_Functions   A.5.1(3)         Pure
Ada.Real_Time   D.8(3)
Ada.Sequential_IO   A.8.1(2)
Ada.Storage_IO   A.9(3)                                      Preelaborate
    No -- depends on System.
Ada.Streams   13.13.1(2)                                     Pure
Ada.Streams.Stream_IO   A.12.1(3)
Ada.Strings   A.4.1(3)                                       Pure
Ada.Strings.Bounded   A.4.4(3)                               Preelaborate
    No -- depends on Ada.Strings.Maps.
    This means Bounded_Strings cannot be transported.
Ada.Strings.Fixed   A.4.3(5)                                 Preelaborate
    No -- depends on Ada.Strings.Maps.
    This means the functions in this package cannot be called from
    the specification of a remote types package.
Ada.Strings.Maps   A.4.2(3)                                  Preelaborate
    No -- access type Character_Mapping_Function.
Ada.Strings.Maps.Constants   A.4.6(3)
    No -- depends on Ada.Strings.Maps.
Ada.Strings.Unbounded   A.4.5(3)
    No -- access type String_Access; depends on Ada.Strings.Maps.
    This means Unbounded_Strings cannot easily be passed across partitions.
Ada.Strings.Wide_Bounded   A.4.7(1)
    No -- depends on Ada.Strings.Wide_Maps.
Ada.Strings.Wide_Fixed   A.4.7(1)
    No -- depends on Ada.Strings.Wide_Maps.
Ada.Strings.Wide_Maps   A.4.7(3)
    No -- access type Character_Mapping_Function.
Ada.Strings.Wide_Maps.Wide_Constants   A.4.7(1)
    No -- depends on Ada.Strings.Wide_Maps.
Ada.Strings.Wide_Unbounded   A.4.7(1)
    No -- access type String_Access.
Ada.Synchronous_Task_Control   D.10(3)
    No -- no need to make it a remote types package.
Ada.Tags   3.9(6)
    No -- if type Tag needs to be transported, one can use the External_Tag
    function.
Ada.Task_Attributes   C.7.2(2)
    No -- access type Attribute_Handle.
Ada.Task_Identification   C.7.1(2)
Ada.Text_IO   A.10.1(2)
Ada.Text_IO.Complex_IO   G.1.3(3)
Ada.Text_IO.Editing   F.3.3(3)
Ada.Text_IO.Text_Streams   A.12.2(3)
Ada.Unchecked_Conversion   13.9(3)                           Pure
Ada.Unchecked_Deallocation   13.11.2(3)                      Preelaborate
    No -- a procedure cannot be categorized as a remote types library unit,
    by 8652/0078 (AI-00048).
Ada.Wide_Text_IO   A.11(2)
Ada.Wide_Text_IO.Complex_IO   G.1.4(1)
Ada.Wide_Text_IO.Editing   F.3.4(1)
Ada.Wide_Text_IO.Text_Streams   A.12.3(3)
Interfaces   B.2(3)                                          Pure
Interfaces.C   B.3(4)                                        Pure
Interfaces.C.Pointers   B.3.2(4)                             Preelaborate
    No -- access type Pointer.
Interfaces.C.Strings   B.3.1(3)                              Preelaborate
    No -- access type char_array_access.
Interfaces.COBOL   B.4(7)                                    Preelaborate
    Yes.
Interfaces.Fortran   B.5(4)                                  Pure
System   13.7(3)                                             Preelaborate
    No -- transportation of type Address makes no sense.
    However, note that an implementation is allowed to add pragma
    Remote_Types if it wants to.
System.Address_To_Access_Conversions   13.7.2(2)             Preelaborate
    No -- access type Object_Pointer.
System.Machine_Code   13.8(7)
    Don't care -- entire contents are implementation defined, so we don't
    need to say anything about this one.
System.RPC   E.5(3)
    No -- RPC is used in the implementation of inter-partition communication,
    so it doesn't make sense to make it a remote types package.
System.Storage_Elements   13.7.1(2)                          Preelaborate
    No -- depends on System.
System.Storage_Pools   13.11(5)                              Preelaborate
    No -- depends on System.
</UL></TT></PRE>

<P><BR><BR></P>
<HR>

<A NAME="8652/0021"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0021 -  Extension aggregates with controlled subcomponents</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00182<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 7.6;  7.6.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Question 1:
</P>
<P>7.6(11) says: &quot;For an extension_aggregate whose ancestor_part is a
subtype_mark, Initialize is called on all controlled subcomponents of
the ancestor part&quot;.
</P>
<P>This seems inappropriate in the case of a controlled subcomponent for
which a default initial value has been given.  What is the intent?
</P>
<P>Question 2:
</P>
<P>7.6.1(13) says: &quot;The anonymous objects created by function calls ... are
finalized no later than the end of the innermost enclosing
declarative_item or statement.&quot;
</P>
<P>This rule permits a reference to a finalized object in the case where
the function call is used as a name in an object renaming declaration:
</P>
<PRE><TT><UL>X : Some_Controlled_Type <B>renames</B> Some_Function_Call;
</UL></TT></PRE>
<P>and similarly when the function call is used as an actual parameter for
a generic formal in out parameter, or when a component of the object
returned by the function call is renamed.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For an extension_aggregate whose ancestor_part is a subtype_mark, for
each controlled subcomponent of the ancestor part, either Initialize is
called, or the default initial value is assigned, as appropriate.
</P>
<P>7.6.1(13) is modified so that an anonymous object is not finalized until
after it is no longer accessible via any name.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.6(11):   </FONT></B></P>
<UL><P>For an <FONT FACE="Arial, Helvetica">extension_aggregate</FONT> whose <FONT FACE="Arial, Helvetica">ancestor_part</FONT> is a <FONT FACE="Arial, Helvetica">subtype_mark</FONT>,
Initialize is called on all controlled subcomponents of the ancestor part; if
the type of the ancestor part is itself controlled, the Initialize procedure
of the ancestor type is called, unless that Initialize procedure is abstract.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For an <FONT FACE="Arial, Helvetica">extension_aggregate</FONT> whose <FONT FACE="Arial, Helvetica">ancestor_part</FONT> is a <FONT FACE="Arial, Helvetica">subtype_mark</FONT>,
for each controlled subcomponent of the ancestor part, either Initialize
is called, or its initial value is assigned, as appropriate; if the
type of the ancestor part is itself controlled, the Initialize procedure of
the ancestor type is called, unless that Initialize procedure is abstract.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.6.1(13):   </FONT></B></P>
<UL><P>The anonymous objects created by function calls and by <FONT FACE="Arial, Helvetica">aggregate</FONT>s are
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>, they are finalized
before starting the execution of any <FONT FACE="Arial, Helvetica">statement</FONT> within the
<FONT FACE="Arial, Helvetica">compound_statement</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>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 anonymous
object created by a function call or by an <FONT FACE="Arial, Helvetica">aggregate</FONT> is 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>, the object is finalized
before starting the execution of any <FONT FACE="Arial, Helvetica">statement</FONT> within the
<FONT FACE="Arial, Helvetica">compound_statement</FONT>.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Question 1:
</P>
<P>The intent is that Initialize should not be called when there is an
initial value to be assigned.
</P>
<P>Question 2:
</P>
<P>The intent is that such renamed objects should not be finalized until
they are no longer &quot;in use&quot;.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0022"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0022 -  Aggregates of a controlled type</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00083<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 7.6</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>If an object of a controlled type is declared in the same package as
the type, and initialized with an aggregate, is Program_Error raised?
(No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>When an (extension) aggregate of a controlled type is assigned other
than by an assignment or return statement, the aggregate is built &quot;in place&quot;.
No anonymous object is created and Adjust is not called on the target object.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  7.6(17):   </FONT></B></P>
<UL><P>For an <FONT FACE="Arial, Helvetica">assignment_statement</FONT>, after the <FONT FACE="Arial, Helvetica">name</FONT> and <FONT FACE="Arial, Helvetica">expression</FONT>
have been evaluated, and any conversion (including constraint checking)
has been done, an anonymous object is created, and the value is assigned
into it; that is, the assignment operation is applied. (Assignment includes
value adjustment.) The target of the <FONT FACE="Arial, Helvetica">assignment_statement</FONT> is then
finalized. The value of the anonymous object is then assigned into the
target of the <FONT FACE="Arial, Helvetica">assignment_statement</FONT>. Finally, the anonymous object is
finalized. As explained below, the implementation may eliminate the
intermediate anonymous object, so this description subsumes the one given
in 5.2, ``Assignment Statements''.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P><I><FONT SIZE=-2>Implementation Requirements</FONT></I><BR>
For an <FONT FACE="Arial, Helvetica">aggregate</FONT> of a controlled type whose value is assigned, other than
by an <FONT FACE="Arial, Helvetica">assignment_statement</FONT> or a <FONT FACE="Arial, Helvetica">return_statement</FONT>, the implementation
shall not create a separate anonymous object for the <FONT FACE="Arial, Helvetica">aggregate</FONT>. The
aggregate value shall be constructed directly in the target of the assignment
operation and Adjust is not called on the target object.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>When an aggregate of a controlled type is created and immediately assigned
into an object other than in an assignment or return statement (that is in
an initial expression, subaggregate, formal parameter, generic in parameter,
or allocator), the implementation must not create a separate anonymous
object for the aggregate; it must create the value of the aggregate directly
in the target object. Thus, there is no assignment from the anonymous object
to the target object, so the Finalize and Adjust that would be done for that
assignment are not done.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Consider the following controlled type:
</P>
<PRE><TT><UL><B>type</B> Dyn_String <B>is</B> <B>private</B>;
Null_String : <B>constant</B> Dyn_String;
...
<B>private</B>
<B>type</B> Dyn_String <B>is</B> <B>new</B> Ada.Finalization.Controlled
  <B>with</B> <B>record</B>
    ...
  <B>end</B> <B>record</B>;
<B>procedure</B> Finalize(X : <B>in</B> <B>out</B> Dyn_String);
<B>procedure</B> Adjust(X : <B>in</B> <B>out</B> Dyn_String);
</UL></TT></PRE>
<PRE><TT><UL>Null_String : <B>constant</B> Dyn_String :=
  (Ada.Finalization.Controlled <B>with</B> ...);
</UL></TT></PRE>
<P>Clearly, at the time when the full constant declaration for Null_String
is elaborated, the bodies for Finalize and Adjust have not yet been
elaborated.  7.6(21) gives the permission to build the aggregate
directly in the target object, thereby eliminating the need for the
assignment (and the associated calls on Adjust/Finalize):
</P>
<P><UL>For an aggregate or function call whose value is assigned into a
target object, the implementation need not create a separate
anonymous object if it can safely create the value of the
aggregate or function call directly in the target object.
</UL></P>
<P>However, it seems important to <I>require</I> this behavior, so that this
kind of programming is portable (that is, it will work portably without
raising Program_Error due to an access-before-elaboration from calling
Adjust or Finalize before their bodies are elaborated).
</P>
<P>In other words, the first sentence of 7.6(21) should be an
implementation requirement in the case where a new object is being
created.
</P>
<P>Note that no Adjust ever takes place on an aggregate as a whole, since
there is no assignment to the aggregate as a whole (4.3(5) and AARM 4.3(5.b)).
AARM 7.6(21.a) talks about this case, and says that &quot;only one value
adjustment is necessary&quot;.  This is misleading.  It should say that only
one adjustment of each controlled <I>subcomponent</I> (if any) is necessary
in this case.  <I>No</I> adjustments of the object as a whole are necessary
(and as suggested above, such adjustments should be disallowed).
</P>
<P>Note that this interpretation applies to all object creations, not just
to object_declarations.  Thus, continuing the above example, if we have:
</P>
<PRE><TT><UL><B>type</B> Dyn_String_Ptr <B>is</B> <B>access</B> <B>all</B> Dyn_String;
Null_String_Ptr: Dyn_String_Ptr :=
  <B>new</B> Dyn_String'(Ada.Finalization.Controlled <B>with</B> ...);
</UL></TT></PRE>
<P>The aggregate must be built directly in the newly-created heap object.
</P>
<P>Similarly, if we have
</P>
<PRE><TT><UL><B>function</B> Is_Null (Value : <B>in</B> Dyn_String) <B>return</B> Boolean;
</UL></TT></PRE>
<P>then the aggregate actual parameter in the call
</P>
<PRE><TT><UL><B>if</B> Is_Null ((Ada.Finalization.Controlled <B>with</B> ...)) <B>then</B>
</UL></TT></PRE>
<P>is built directly in a temporary object, and Adjust is not called on the object
as a whole.
</P>
<P>We exempt assignment and return statements from this requirement as there is
no compelling reason to burden implementations with this requirement in those
cases.
</P>
<P>Note that all aggregates of a controlled type are extension aggregates:
Controlled and Limited_Controlled are private, so it is not possible to
create a normal record aggregate for such a type.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0023"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0023 -  Exceptions raised by Adjust/Finalize -- missing cases</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00169<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 7.6.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>7.6.1(14-20) list a variety of situations in which Finalize and Adjust
may raise exceptions, and the possible consequences.
</P>
<P>It does not seem to indicate what happens when an exception is raised in
a Finalize which is part of the finalization of a master due to the most
normal type of completion--reaching the end of the execution.  What is
the intended semantics for this situation? (Any pending finalizations
are performed and Program_Error is raised.)
</P>
<P>If the finalization of an anonymous object raises an exception what
should occur? (Program_Error is raised at the point of finalization.)
</P>
<P>If a transfer of control or raising of an exception occurs prior to
performing a finalization of an anonymous object, when is the object
finalized? (The anonymous object is finalized as part of the finalization
of the innermost enclosing master.)
</P>
<P>If an explicit call to Adjust or Finalize propagates an exception,
is the exception converted to Program_Error? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If a call to Finalize propagates an exception when invoked as part of
the finalization of a master, Program_Error is raised at the point where
normal execution would have continued following the master's finalization.
Any other finalizations due to be performed up to that point are performed
before raising Program_Error.
</P>
<P>If a call to Finalize propagates an exception in the case of finalizing an
anonymous object created for a function call or aggregate, Program_Error
is raised at the point where normal execution would have continued
following the object's finalization.
</P>
<P>For finalizations of objects that occur as the result of transfers of
control or the raising of an exception, the finalization of an anonymous
object occurs as part of the finalizations due to be performed
for the innermost enclosing master of the anonymous object.
</P>
<P>For an explicit call to Adjust or Finalize that propagates an exception,
the exception is propagated as for a normal call to a user-defined
subprogram that propagates an exception.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  7.6.1(13):   </FONT></B></P>
<UL><P>The anonymous objects created by function calls and by <FONT FACE="Arial, Helvetica">aggregate</FONT>s are
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>, they are finalized
before starting the execution of any <FONT FACE="Arial, Helvetica">statement</FONT> within the
<FONT FACE="Arial, Helvetica">compound_statement</FONT>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>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.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.6.1(14):   </FONT></B></P>
<UL><P>It is a bounded error for a call on Finalize or Adjust to propagate an
exception. The possible consequences depend on what action invoked the
Finalize or Adjust operation:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>It is a bounded error for a call on Finalize or Adjust that occurs
as part of object finalization or assignment to propagate an exception.
The possible consequences depend on what action invoked the
Finalize or Adjust operation:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  7.6.1(17):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
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></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
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.</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
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.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The lack of a rule describing what happens when a call to Finalize
propagates an exception during the finalization of a master is
an oversight.  The intended semantics is to treat this case
similarly to what happens when Finalize propagates an exception
when invoked by the transfer of control of a return statement
(as defined by 7.6.1(18)).  Any finalizations due to be performed
are carried out and Program_Error is raised at the point where
normal execution would have continued.
</P>
<P>There is also no mention of what should happen when a call to Finalize
propagates an exception when finalizing an anonymous object.  Since
such objects are not directly associated with a master, the rules
of 7.6.1(14-20) don't appear to explain what should happen.  The
intended semantics is to raise Program_Error as in the case of other
implicit calls to Finalize.  The exception is raised immediately
following the point where the Finalize operation is invoked (as defined
by 7.6.1(13)).  Also, in the presence of transfers of control or the
raising of an exception, the finalization of anonymous objects
occurs as part of the &quot;finalizations due to be performed&quot; mentioned
in the rules of 7.6.1(18-19).
</P>
<P>In the case of explicitly invoked Adjust and Finalize operations,
any exception propagated by such calls should simply be propagated
as for an exception propagation that occurs as part of a call to
any other user-defined subprogram.  There is no benefit in requiring such
exceptions to be converted to Program_Error.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0024"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0024 -  Initialize, Adjust, and exceptions</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00193<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 7.6.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>If an object that is initialized by assignment fails during
an Adjust operation, should the object nevertheless be finalized?
(This is unspecified.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For a controlled object (including a component) that is initialized
explicitly by assignment (possibly to an enclosing object), if its Adjust
procedure is invoked but then fails by propagating an exception,
it is not specified by the language whether the object is finalized.
If the object is initialized by assignment from an aggregate, its
Adjust procedure is not invoked (per 8652/0022 [AI-00083]), but it is
finalized if and only if the initialization is successful.
If it is initialized by assignment from something other
than an aggregate, but its Adjust procedure is not invoked at all
because initialization fails before that point, then the object is
not finalized.
</P>
<P>For an object that is initialized by default, the object is not
finalized unless default initialization completes successfully, i.e.
without propagating an exception.
</P>
<P>For an Adjust invoked as part of initialization, if it propagates
an exception, no other adjustments need be performed prior to
raising Program_Error.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  7.6.1(16):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
For an Adjust invoked as part of an assignment operation, any
other adjustments due to be performed are performed, and then Program_Error
is raised.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
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. For an Adjust invoked
as part of an assignment statement, any other adjustments due to be performed
are performed, and then Program_Error is raised.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>7.6.1(4) says:
</P>
<P><UL>... each object ... is finalized if the object was successfully
initialized and still exists.
</UL></P>
<P>This is relaxed for objects that are initialized by
assignment when an Adjust propagates an exception.  For such
objects, the object may be finalized so long as the Adjust operation
is invoked, even if it propagates an exception.  It must be finalized
if the Adjust operation completes successfully.
</P>
<P>For objects which are initialized by default, no change in the
wording is proposed; such objects are finalized if and only if
default initialization completes without propagating an exception.
</P>
<P>The definition of &quot;adjustments due to be performed&quot; should be
relaxed for an assignment operation that is part of initialization,
thereby allowing initialization to be abandoned as soon as any
Adjust fails.  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.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>When an object (including a component) is initialized by an assignment
other than from an aggregate, the Adjust operation is invoked.
If this operation propagates an exception, then other Adjust operations
that are already due to be performed are performed, and then Program_Error
is raised.
</P>
<P>What this means is that if you have a composite object which is
initialized by an assignment from something other than an aggregate,
and it has multiple controlled parts, then if one of the Adjust
operations fails, the others are still invoked.  Clearly those parts for
which Adjust succeeds should be finalized per 7.6.1(4).  However,
7.6.1(4) implies that the ones for which Adjust fails should not be
finalized.  However, for implementations that &quot;bundle&quot; all of the Adjust
operations for all controlled parts of a composite type into a single
&quot;adjust-whole-object&quot; procedure, it is burdensome to keep track
of which parts failed and which succeeded, and only finalize those
whose Adjust succeeded.  Note that if some of the Adjust operations
had failed in an assignment statement, all parts would ultimately
still be finalized when the master is left.
</P>
<P>One of the important goals of the finalization model with respect to
exceptions (see 7.6.1(14-18)) is that if one controlled
abstraction fails by raising an exception in Adjust or
Finalize, this failure should not spread to other unrelated controlled
abstractions.  Even when one composite object happens to have
two controlled parts, one from the &quot;failed&quot; abstraction and one
from the &quot;still-good&quot; abstraction, the &quot;still-good&quot; abstraction should
still have Adjust and Finalize called the appropriate number of times
to keep reference counts correct, avoid dangling pointers, etc.
</P>
<P>Given this goal, the &quot;bundling&quot; of Adjust operations, and the
correspondence with assignment statements, it seems best to
allow that, so long as the Adjust routine has been invoked on an
object being initialized, Finalize may be invoked on the object.
</P>
<P>On a somewhat separate issue, the notion of adjustments
&quot;due to be performed&quot; (7.6.1(16)) need not apply to initialization
by assignment.  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.  On the other hand,
for an assignment that is part of an assignment statement,
it is important that all adjustments be attempted, even if some
of them fail, since all subcomponents are going to be finalized.
This relaxation for adjustments that occur during initialization
means that an initialization may be abandoned as soon as any
Adjust fails, so long as those components which have never been
adjusted are not finalized.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0025"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0025 -  Overriding by implicit declarations</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00044<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 8.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>8.3(9-13) do not cover the case of an implicitly declared &quot;/=&quot; that
corresponds to an explicitly declared &quot;=&quot; operator.  Is it the intent
that such a &quot;/=&quot; operator overrides a predefined &quot;/=&quot;?  (Yes.)
</P>
<P>These paragraphs also fail to cover the case of a statement_identifier.
Is it the intent that a statement_identifier overrides an inherited
subprogram with the same name?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For an explicit declaration of &quot;=&quot;, the corresponding &quot;/=&quot; that is
implicitly declared (if any) overrides the predefined &quot;/=&quot; (if any).
</P>
<P>The implicit declaration of a statement_identifier overrides the
implicit declaration of an inherited subprogram with the same
identifier.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.3(9):   </FONT></B></P>
<UL><P>Two homographs are not generally allowed immediately within the same
declarative region unless one <I>overrides</I> the other (see Legality Rules below).
A declaration overrides another homograph that occurs immediately within the
same declarative region in the following cases:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Two homographs are not generally allowed immediately within the same
declarative region unless one <I>overrides</I> the other (see Legality Rules
below). The only declarations that are <I>overridable</I> are the implicit
declarations for predefined operators and inherited primitive subprograms.
A declaration overrides another homograph that occurs immediately within
the same declarative region in the following cases:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.3(10):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
An explicit declaration overrides an implicit declaration of a
primitive subprogram, regardless of which declaration occurs first;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
A declaration that is not overridable overrides one that is
overridable, regardless of which declaration occurs first;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.3(26):   </FONT></B></P>
<UL><P>An explicit declaration is illegal if there is a homograph occurring
immediately within the same declarative region that is visible at the place
of the declaration, and is not hidden from all visibility by the explicit
declaration. Similarly, the <FONT FACE="Arial, Helvetica">context_clause</FONT> for a <FONT FACE="Arial, Helvetica">subunit</FONT> is illegal if it
mentions (in a <FONT FACE="Arial, Helvetica">with_clause</FONT>) some library unit, and there is a homograph of
the library unit that is visible at the place of the corresponding stub, and
the homograph and the mentioned library unit are both declared immediately
within the same declarative region. These rules also apply to dispatching
operations declared in the visible part of an instance of a generic unit.
However, they do not apply to other overloadable declarations in an instance;
such declarations may have type conformant profiles in the instance, so long
as the corresponding declarations in the generic were not type conformant.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A non-overridable declaration is illegal if there is a homograph occurring
immediately within the same declarative region that is visible at the place
of the declaration, and is not hidden from all visibility by the non-overridable
declaration. Similarly, the <FONT FACE="Arial, Helvetica">context_clause</FONT> for a <FONT FACE="Arial, Helvetica">subunit</FONT> is illegal if it
mentions (in a <FONT FACE="Arial, Helvetica">with_clause</FONT>) some library unit, and there is a homograph of
the library unit that is visible at the place of the corresponding stub, and
the homograph and the mentioned library unit are both declared immediately
within the same declarative region. These rules also apply to dispatching
operations declared in the visible part of an instance of a generic unit.
However, they do not apply to other overloadable declarations in an instance;
such declarations may have type conformant profiles in the instance, so long
as the corresponding declarations in the generic were not type conformant.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>For the &quot;/=&quot; issue, clearly it would be confusing if the predefined &quot;/=&quot;
were visible instead of the one corresponding to the user-defined &quot;=&quot;.
</P>
<P>For the statement_identifier issue, clearly the statement_identifier
should override, because although the declaration is implicit, the
statement_identifier itself is sitting right there in the code.
Furthermore, we don't want to have a case where a non-overloadable
declaration is overloaded, which would be the case if the
statement_identifier did not hide, and both were visible.  This
interpretation is also necessary for upward compatibility, because in
Ada 83, a statement_identifier hides an inherited subprogram.  This is
illustrated by validation test B83033B.
</P>
<P>In retrospect, it was probably a mistake to base the definition of
overriding on whether or not a declaration is implicit.  A better model
might be as follows:
</P>
<P>The implicit declaration of a predefined operator or an inherited
subprogram is an &quot;overridable declaration&quot;.
[Only overridable declarations may be overridden.]
</P>
<P>If two or more homographs occur immediately within the same declarative
region, then:
</P>
<P><UL>1) at most one of them is allowed to be a non-overridable declaration;
</UL></P>
<P><UL>2) a non-overridable declaration overrides an overridable declaration,
independent of which comes first;
</UL></P>
<P><UL>3) an inherited subprogram overrides a predefined operator,
except for equality of tagged types, where the reverse applies;
</UL></P>
<P><UL>4) for those pairs for which (1) to (3) don't apply, a later
overridable declaration overrides an earlier one.
</UL></P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0026"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0026 -  Uniqueness of component names</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00150<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 8.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider the following example, inspired by validation test C730003:
</P>
<PRE><TT><UL><B>package</B> Parent <B>is</B>
   <B>type</B> T <B>is</B> <B>tagged</B> ...;
   <B>type</B> DT <B>is</B> <B>new</B> T <B>with</B> <B>private</B>;
<B>private</B>
   <B>type</B> DT <B>is</B> <B>new</B> T <B>with</B> <B>record</B>
      Y: ...;
   <B>end</B> <B>record</B>;
<B>end</B> Parent;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> Parent.Child <B>is</B>
   <B>type</B> DDT <B>is</B> <B>new</B> DT <B>with</B> <B>record</B>
      Y: ...; -- Legal?  (No.)
   <B>end</B> <B>record</B>;
<B>end</B> Parent.Child;
</UL></TT></PRE>
<P>Both DT and DDT contain components called Y.  Is this name duplication
legal?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A type extension is illegal if somewhere within its immediate scope it has two
visible components with the same name. See also 8652/0102 (AI-00157).
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.3(26):   </FONT></B></P>
<UL><P>An explicit declaration is illegal if there is a homograph occurring
immediately within the same declarative region that is visible at the place
of the declaration, and is not hidden from all visibility by the explicit
declaration. Similarly, the <FONT FACE="Arial, Helvetica">context_clause</FONT> for a <FONT FACE="Arial, Helvetica">subunit</FONT> is illegal if it
mentions (in a <FONT FACE="Arial, Helvetica">with_clause</FONT>) some library unit, and there is a homograph of
the library unit that is visible at the place of the corresponding stub, and
the homograph and the mentioned library unit are both declared immediately
within the same declarative region. These rules also apply to dispatching
operations declared in the visible part of an instance of a generic unit.
However, they do not apply to other overloadable declarations in an instance;
such declarations may have type conformant profiles in the instance, so long
as the corresponding declarations in the generic were not type conformant.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An explicit declaration is illegal if there is a homograph occurring
immediately within the same declarative region that is visible at the place
of the declaration, and is not hidden from all visibility by the explicit
declaration. In addition, a type extension is illegal if somewhere within
its immediate scope it has two visible components with the same name. Similarly,
the <FONT FACE="Arial, Helvetica">context_clause</FONT> for a <FONT FACE="Arial, Helvetica">subunit</FONT> is illegal if it mentions (in a
<FONT FACE="Arial, Helvetica">with_clause</FONT>) some library unit, and there is a homograph of the library
unit that is visible at the place of the corresponding stub, and the homograph
and the mentioned library unit are both declared immediately within the same
declarative region. These rules also apply to dispatching operations declared in
the visible part of an instance of a generic unit. However, they do not apply to
other overloadable declarations in an instance; such declarations may have type
conformant profiles in the instance, so long as the corresponding declarations
in the generic were not type conformant.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>3.4(14) says:
</P>
<P><UL>Declarations of components, protected subprograms, and entries,
whether implicit or explicit, occur immediately within the
declarative region of the type, in the order indicated above,
following the parent subtype_indication.
</UL></P>
<P>8.3(26) says:
</P>
<P><UL>An explicit declaration is illegal if there is a homograph occurring
immediately within the same declarative region that is visible at the
place of the declaration, and is not hidden from all visibility by
the explicit declaration.
</UL></P>
<P>It appears that this rule does not apply to the second declaration of Y,
above, because the inherited Y is not visible at this place.  However,
the inherited Y later does become visible, since DDT is in a child
package.  This is intended to be illegal -- components are not intended
to be overridable; nor are they allowed to be overloadable.
</P>
<P>The problem is that 8.3(26) and other parts of 8.3 are based on whether
certain declarations are implicit or explicit.  This leads to the
problem addressed by this issue.  See also 8652/0025 (AI-00044), which
addresses other problems with the same underlying cause.
</P>
<P>The intent is that two or more homographs are not allowed immediately
within the same declarative region, if there is a place where both are
visible, unless all but one are overridden.  (Note however, that this
rule does not apply in instances!)
</P>
<P>Note that if DDT were declared in another root library unit, rather than
in a child of Parent, then the two Y's would be legal, since there would
be no place where both are visible.
</P>
<P>This problem can occur anytime components can become visible after the initial
declaration. Consider:
</P>
<PRE><TT><UL><B>package</B> A <B>is</B>
    <B>type</B> Foo <B>is</B> <B>tagged</B> <B>private</B>;
    <B>package</B> B <B>is</B>
        <B>type</B> New_Foo <B>is</B> <B>new</B> Foo <B>with</B> <B>record</B>
           I: Integer; -- Illegal because Foo.I is visible in the body.
        <B>end</B> <B>record</B>; -- Foo.I is not visible here.
    <B>end</B> C;
<B>private</B>
    <B>type</B> Foo <B>is</B>  <B>tagged</B> <B>record</B>  I: Integer; <B>end</B> <B>record</B>;
<B>end</B> A;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> A <B>is</B>
    <B>package</B> <B>body</B> B <B>is</B>
        -- Foo.I becomes visible here, but that means we have two components
        -- with the same name visible in same record.
    <B>end</B> C;
<B>end</B> B;
</UL></TT></PRE>
<P>Because of this, the new rule simply says that it is illegal for two components
with the same name to ever be visible.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0027"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0027 -  Circular renamings as body</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00135<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 8.5.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>package</B> Example <B>is</B>
   <B>function</B> F <B>return</B> Boolean;
   <B>function</B> G <B>return</B> Boolean <B>renames</B> F;
   <B>function</B> H <B>return</B> Boolean <B>renames</B> G;
<B>private</B>
   <B>function</B> F <B>return</B> Boolean <B>renames</B> H; -- Legal?  (No.)
<B>end</B> Example;
</UL></TT></PRE>
<P>8.5.4(5) says:
</P>
<P><UL>The profile of a renaming-as-body shall be subtype-conformant with that
of the renamed callable entity, and shall conform fully to that of the
declaration it completes.  If the renaming-as-body completes that declaration
before the subprogram it declares is frozen, the subprogram it declares takes
its convention from the renamed subprogram; otherwise the convention of the
renamed subprogram shall not be Intrinsic.
</UL></P>
<P>In the above example, the renaming-as-body for F occurs before F is
frozen.  Therefore, F takes its calling convention from H, which comes
from G, which comes from F.  So what is the calling convention of F?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A circular renaming-as-body represents infinite recursion.  If the
renaming-as-body occurs before the subprogram whose body is being
defined is frozen, the renaming-as-body is illegal.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.5.4(5):   </FONT></B></P>
<UL><P>The profile of a renaming-as-body shall be subtype-conformant with that
of the renamed callable entity, and shall conform fully to that of the
declaration it completes. If the renaming-as-body completes that declaration
before the subprogram it declares is frozen, the subprogram it declares takes
its convention from the renamed subprogram; otherwise the convention of the
renamed subprogram shall not be Intrinsic.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The profile of a renaming-as-body shall be subtype-conformant with that
of the renamed callable entity, and shall conform fully to that of the
declaration it completes. If the renaming-as-body completes that declaration
before the subprogram it declares is frozen, the subprogram it declares takes
its convention from the renamed subprogram; otherwise the convention of the
renamed subprogram shall not be Intrinsic. A renaming-as-body is illegal if the
declaration occurs before the subprogram whose declaration it completes is
frozen, and the renaming renames the subprogram itself, through one or more
subprogram renaming declarations, none of whose subprograms has been frozen.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  8.5.4(8):   </FONT></B></P>
<UL><P>For a call on a renaming of a dispatching subprogram that is overridden,
if the overriding occurred before the renaming, then the body executed is
that of the overriding declaration, even if the overriding declaration is not
visible at the place of the renaming; otherwise, the inherited or predefined
subprogram is called.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P><I><FONT SIZE=-2>Bounded (Run-Time) Errors</FONT></I>
</P></UL>
<UL><P>If a subprogram directly or indirectly renames itself, then it is a bounded
error to call that subprogram. Possible consequences are that Program_Error
or Storage_Error is raised, or that the call results in infinite recursion.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>For a subprogram whose body is defined by a renaming-as-body, if the
rule in 8.5.4(5) requires the calling convention of the subprogram to be
taken ultimately from itself, then the renaming-as-body is illegal.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>In the above example, the definition of the calling convention of F is
not well-defined, because of the circular definition in 8.5.4(5).
Therefore, we choose to make this case illegal.
</P>
<P>An alternative would be to define the calling convention to be Ada in
this case.  However, the compiler needs to detect the circularity
anyway, in order to avoid an infinite loop during semantic analysis.
Therefore, we might as well let the compiler give an error message,
rather than generating infinitely-recursive code.
</P>
<P>Note that some circularities are legal.  In particular, if the
renaming-as-body completes a subprogram <I>after</I> that subprogram is
frozen, the circularity is legal, and will be infinitely recursive at
run time.  For example:
</P>
<PRE><TT><UL><B>package</B> Pack_1 <B>is</B>
    <B>procedure</B> P;
<B>end</B> Pack_1;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> Pack_2 <B>is</B>
    <B>procedure</B> Q;
<B>end</B> Pack_2;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Pack_2;
<B>package</B> <B>body</B> Pack_1 <B>is</B>
    <B>procedure</B> P <B>renames</B> Pack_2.Q;
<B>end</B> Pack_1;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Pack_1;
<B>package</B> <B>body</B> Pack_2 <B>is</B>
    <B>procedure</B> Q <B>renames</B> Pack_1.P;
<B>end</B> Pack_2;
</UL></TT></PRE>
<P>The above is legal, the convention of P and Q is Ada, and a call to P or
Q will be infinitely recursive.  Note that we don't want to make <I>this</I>
case illegal, since it cannot be detected at compile time.
</P>
<P>Here is another example of legal circularity:
</P>
<PRE><TT><UL><B>type</B> Ptr <B>is</B> <B>access</B> <B>function</B> <B>return</B> Integer:
<B>function</B> F <B>return</B> Integer;
P: Ptr := F'<B>access</B>;
<B>function</B> F <B>return</B> Integer <B>renames</B> P.all;
</UL></TT></PRE>
<P>The convention of P.all is Ada, by 6.3.1(3).  F is frozen by the
declaration of P, by 13.14(6,4,11).  Therefore, 8.5.4(5) does not
specify the convention of F; it defaults to Ada, and the subtype
conformance required by 8.5.4(5) is satisfied.
</P>
<P>Any call to F or P.all will result in infinite recursion.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0028"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0028 -  Profile of predefined operators for scalar types</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00145<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 8.5.4;  A.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>4.5.2(8-9) say:
</P>
<P><UL>The ordering operators are predefined for every specific scalar type T,
and for every discrete array type T, with the following specifications:
</UL></P>
<PRE><TT><UL><B>function</B> &quot;&lt;&quot; (Left, Right : T) <B>return</B> Boolean
...
</UL></TT></PRE>
<P>where the T is in italics.  Similar definitions are given throughout
section 4 for other predefined operators.  What is the meaning of this
italicized type name notation?  Presumably, it is intended to refer to
the base subtype, at least in some cases.
</P>
<P>However, the predefined operators shown in package Standard do not
always use the base subtype:
</P>
<PRE><TT><UL><B>function</B> &quot;&lt;&quot; (Left, Right : Boolean) <B>return</B> Boolean; -- A.1(7)
<B>function</B> &quot;&lt;&quot; (Left, Right : Integer'Base) <B>return</B> Boolean; -- A.1(15)
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The italicized T shown in the definitions of predefined operators means:
</P>
<P><UL>- T'Base, for scalars
</UL></P>
<P><UL>- the first subtype, for tagged types
</UL></P>
<P><UL>- the type without any constraint, in other cases
</UL></P>
<P>The definitions of the operators in section 4 take precedence over those
shown in A.1 in package Standard; for example, the &quot;&lt;&quot; operator on type
Boolean has parameters of subtype Boolean'Base, not Boolean.
</P>
<P>If a renaming-as-body completes a declaration before the subprogram it
declares is frozen, then the profile of the renaming-as-body need not be
subtype-conformant with that of the renamed callable entity.  The
profile of such a renaming-as-body must instead be mode conformant with
that of the renamed callable entity.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  8.5.4(5):   </FONT></B></P>
<UL><P>The profile of a renaming-as-body shall be subtype-conformant with that
of the renamed callable entity, and shall conform fully to that of the
declaration it completes.  If the renaming-as-body completes that declaration
before the subprogram it declares is frozen, the subprogram it declares takes
its convention from the renamed subprogram; otherwise the convention of the
renamed subprogram shall not be Intrinsic.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The profile of a renaming-as-body shall conform fully to that of the
declaration it completes. If the renaming-as-body completes that
declaration before the subprogram it declares is frozen, the profile
shall be mode-conformant with that of the renamed callable entity
and the subprogram it declares takes its convention from the renamed
subprogram; otherwise the profile shall be subtype-conformant with
that of the renamed callable entity and the convention of the
renamed subprogram shall not be Intrinsic.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.1(7):   </FONT></B></P>
<UL><UL><PRE><TT>    -- <B>function</B> &quot;=&quot;   (Left, Right : Boolean) <B><B>return</B></B> Boolean;
    -- <B>function</B> &quot;/=&quot;  (Left, Right : Boolean) <B>return</B> Boolean;
    -- <B>function</B> &quot;&lt;&quot;   (Left, Right : Boolean) <B>return</B> Boolean;
    -- <B>function</B> &quot;&lt;=&quot;  (Left, Right : Boolean) <B>return</B> Boolean;
    -- <B>function</B> &quot;&gt;&quot;   (Left, Right : Boolean) <B>return</B> Boolean;
    -- <B>function</B> &quot;&gt;=&quot;  (Left, Right : Boolean) <B>return</B> Boolean;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>    -- <B>function</B> &quot;=&quot;   (Left, Right : Boolean'Base) <B>return</B> Boolean;
    -- <B>function</B> &quot;/=&quot;  (Left, Right : Boolean'Base) <B>return</B> Boolean;
    -- <B>function</B> &quot;&lt;&quot;   (Left, Right : Boolean'Base) <B>return</B> Boolean;
    -- <B>function</B> &quot;&lt;=&quot;  (Left, Right : Boolean'Base) <B>return</B> Boolean;
    -- <B>function</B> &quot;&gt;&quot;   (Left, Right : Boolean'Base) <B>return</B> Boolean;
    -- <B>function</B> &quot;&gt;=&quot;  (Left, Right : Boolean'Base) <B>return</B> Boolean;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.1(9):   </FONT></B></P>
<UL><UL><PRE><TT>    -- <B>function</B> &quot;and&quot; (Left, Right : Boolean) <B>return</B> Boolean;
    -- <B>function</B> &quot;or&quot;  (Left, Right : Boolean) <B>return</B> Boolean;
    -- <B>function</B> &quot;xor&quot; (Left, Right : Boolean) <B>return</B> Boolean;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>    -- <B>function</B> &quot;and&quot; (Left, Right : Boolean'Base) <B>return</B> Boolean'Base;
    -- <B>function</B> &quot;or&quot;  (Left, Right : Boolean'Base) <B>return</B> Boolean'Base;
    -- <B>function</B> &quot;xor&quot; (Left, Right : Boolean'Base) <B>return</B> Boolean'Base;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.1(10):   </FONT></B></P>
<UL><UL><PRE><TT>    -- <B>function</B> &quot;not&quot; (Right : Boolean) <B>return</B> Boolean;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>    -- <B>function</B> &quot;not&quot; (Right : Boolean'Base) <B>return</B> Boolean'Base;</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Consider the following type declarations, where the comments show the subtypes
associated with the italicized notation in section 4:
</P>
<PRE><TT><UL><B>type</B> T1 <B>is</B> <B>range</B> ...;                          -- T1'Base
<B>type</B> T2 <B>is</B> <B>tagged</B> ...;                         -- T2
<B>type</B> T3(D: Integer) <B>is</B> <B>tagged</B> ...;             -- T3
<B>type</B> T4 <B>is</B> <B>array</B>(Integer <B>range</B> &lt;&gt;) <B>of</B> Integer; -- T4
<B>type</B> T5 <B>is</B> <B>array</B>(Integer <B>range</B> 1..100)
   <B>of</B> Integer;                                 -- T5-without-the-constraint
<B>type</B> T6 <B>is</B> <B>record</B> ...;                         -- T6
</UL></TT></PRE>
<P>Note that T2 and T6 are constrained, despite the fact
that they have no constraint.  Note also that in the case of T5, the
subtype in question has no name in Ada, since the Base attribute is not
defined for composite types.
</P>
<P>The Boolean operators in A.1 are shown with the wrong subtypes --
Boolean'Base is correct.
</P>
<P>Furthermore, 8.5.4(5) says:
</P>
<P><UL>The profile of a renaming-as-body shall be subtype-conformant with that
of the renamed callable entity, and shall conform fully to that of the
declaration it completes.  If the renaming-as-body completes that declaration
before the subprogram it declares is frozen, the subprogram it declares takes
its convention from the renamed subprogram; otherwise the convention of the
renamed subprogram shall not be Intrinsic.
</UL></P>
<P>However, consider:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    <B>type</B> T <B>is</B> <B>private</B>;
<B>private</B>
    <B>type</B> T <B>is</B> <B>new</B> Integer'Base;
<B>end</B> P;
<B>use</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>function</B> Equals(X, Y: T) <B>return</B> Boolean;
<B>function</B> Equals(X, Y: T) <B>return</B> Boolean <B>renames</B> &quot;=&quot;;
</UL></TT></PRE>
<P>Without this ruling, the above renaming-as-body would be illegal, since it
is not subtype conformant.  However, if the full type declaration were
&quot;type T is new Integer;&quot;, then it would be legal.  It is intolerable for
the contents of the private part to affect the legality of a client in
this way; therefore, we relax the rules for renamings-as-body that
appear before the subprogram is frozen.  Note that after the subprogram
is frozen, one cannot use a renaming-as-body for a predefined operator,
because it is intrinsic.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0029"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0029 -  Elaboration of a task with no task_definition</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00116<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 9.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A legal task_type_declaration is
</P>
<PRE><TT><UL><B>task</B> <B>type</B> TT;
</UL></TT></PRE>
<P>By the grammar in 9.1(2), this task_type_declaration does not
include a task_definition.
</P>
<P>9.1(10) says that the elaboration of a task declaration elaborates
the task_definition; what if there isn't one? (An empty task_definition
is elaborated.)
</P>
<P>9.1(11) says the elaboration of a task_definition creates the task
type and its first subtype; if there is no task_definition, when are
the task type and its first subtype created? (There is an empty
task_definition.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For a task declaration with no task_definition, an empty
task_definition is assumed.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  9.1(9):   </FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">task_definition</FONT> defines a task type and its first subtype. The first
list of <FONT FACE="Arial, Helvetica">task_item</FONT>s of a <FONT FACE="Arial, Helvetica">task_definition</FONT>, together with the
<FONT FACE="Arial, Helvetica">known_discriminant_part</FONT>, if any, is called the visible part of the
task unit. The optional list of <FONT FACE="Arial, Helvetica">task_item</FONT>s after the reserved word
<B>private</B> is called the private part of the task unit.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>For a task declaration without a <FONT FACE="Arial, Helvetica">task_definition</FONT>, a
<FONT FACE="Arial, Helvetica">task_definition</FONT> without <FONT FACE="Arial, Helvetica">task_item</FONT>s is assumed.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The question not only applies to the syntax of 9.1(2) , but equally
to the syntax of 9.1(3), i.e., to all task declarations.
</P>
<P>The intent is clear. The new wording means that
</P>
<PRE><TT><UL><B>task</B> <B>type</B> TT;
</UL></TT></PRE>
<P>is equivalent to
</P>
<PRE><TT><UL><B>task</B> <B>type</B> TT <B>is</B>
<B>end</B> TT;
</UL></TT></PRE>
<P>providing an implicit, empty task_definition.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0030"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0030 -  Exception raised by Month, Day, Seconds in Ada.Calendar?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00113<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 9.6</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>In the Ada.Calendar package, the function Year and the procedure Split
raise Time_Error if the given Date parameter represents a date outside
the range 1901 .. 2099.  What do the functions Month, Day, and Seconds
do with such a date? (Raise Time_Error.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The functions Month, Day, and Seconds in Ada.Calendar raise Time_Error
if the year is outside the range of the subtype Year_Number.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  9.6(26):   </FONT></B></P>
<UL><P>The exception Time_Error is raised by the function Time_Of if the actual
parameters do not form a proper date. This exception is also raised by the
operators &quot;+&quot; and &quot;-&quot; if the result is not representable in the type Time or
Duration, as appropriate. This exception is also raised by the function Year
or the procedure Split if the year number of the given date
is outside of the range of the subtype Year_Number.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The exception Time_Error is raised by the function Time_Of if the actual
parameters do not form a proper date. This exception is also raised by the
operators &quot;+&quot; and &quot;-&quot; if the result is not representable in the type Time or
Duration, as appropriate. This exception is also raised by the functions Year, Month, Day, and
Seconds and the procedure Split if the year number of the given date
is outside of the range of the subtype Year_Number.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The implementation model for these functions is that the procedure Split
is first called and then the required result is extracted. For example
</P>
<PRE><TT><UL><B>function</B> Month (Date : Time) <B>return</B> Month_Number <B>is</B>
   Y : Year_Number;
   M : Month_Number;
   D : Day_Number;
   S : Day_Duration;
<B>begin</B>
   Split(Date, Y, M, D, S);
   <B>return</B> M;
<B>end</B> Month;
</UL></TT></PRE>
<P>If Split raises Time_Error then, by propagation, Month will also raise
Time_Error.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0031"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0031 -  Termination signals query of Terminate attribute</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00118<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 9.10</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider:
</P>
<PRE><TT><UL><B>task</B> <B>body</B> T <B>is</B>
   Stop_Pulse : Integer;
</UL></TT></PRE>
<PRE><TT><UL>   <B>task</B> Local_Task <B>is</B> ... <B>end</B> Local_Task;
</UL></TT></PRE>
<PRE><TT><UL>   <B>task</B> <B>body</B> Local_Task <B>is</B>
   <B>begin</B>
      Stop_Pulse := 17;
   <B>end</B> T1;
</UL></TT></PRE>
<PRE><TT><UL><B>begin</B>
   <B>loop</B>
      <B>if</B> Local_Task'Terminated <B>then</B>
         Rely_On(Stop_Pulse=17); -- Is this erroneous?  (No.)
         <B>exit</B>;
      <B>end</B> <B>if</B>;
   <B>end</B> <B>loop</B>;
<B>end</B> T;
</UL></TT></PRE>
<P>Since there is no signaling as per 9.10(2-10) between the assignment to
Stop_Pulse and any action in task T prior to the call on Rely_On, reliance
on the update to Stop_Pulse by Local_Task is erroneous by 9.10(11).
9.10(6) doesn't apply, since T is not yet (or ever) waiting for the
termination of Local_Task in the Ada technical sense of &quot;waiting&quot;.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A task T2 can rely on values of variables that are updated by another
task T1, if task T2 first verifies that T1'Terminated is True.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  9.10(6):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
If A1 is part of the execution of a task, and A2 is the action of
waiting for the termination of the task;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
If A1 is the termination of a task T, and A2
is either the evaluation of the expression T'Terminated or a call to
Ada.Task_Identification.Is_Terminated with an actual parameter that identifies
T (see C.7.1);</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It would be surprising if T'Terminated were True, but T failed to update
any locally-cached variables, or the querying task failed to see those
updates.
</P>
<P>The wording is written so that Ada.Task_Identificiation.Is_Terminated(&lt;expr&gt;)
(where &lt;expr&gt; evaluates to T'Identity) works the same as T'Terminated. It would
be very surprising if this function, defined to be the same as 'Terminated,
had a different signaling behavior.
</P>
<P>Note that we do not say anything about the Callable attribute; if the
Callable attribute becomes False, the task might still have a local
cache that is inconsistent with global variables.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0032"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0032 -  A library subprogram_body should replace, not complete, an instance</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00192<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 10.1.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Can a library subprogram body ever complete an existing generic instance? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A library subprogram body can be interpreted as the completion of a
generic subprogram or of a subprogram that is not an instance of a generic
subprogram but not as the completion of an instance of a generic subprogram.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  10.1.4(4):   </FONT></B></P>
<UL><P>If a <FONT FACE="Arial, Helvetica">library_unit_body</FONT> that is a <FONT FACE="Arial, Helvetica">subprogram_body</FONT> is submitted to the
compiler, it is interpreted only as a completion if a
<FONT FACE="Arial, Helvetica">library_unit_declaration</FONT> for a subprogram or a generic subprogram
with the same <FONT FACE="Arial, Helvetica">defining_program_unit_name</FONT> already exists in the
environment (even if the profile of
the body is not type conformant with that of the declaration); otherwise the
<FONT FACE="Arial, Helvetica">subprogram_body</FONT> is interpreted as both the declaration and body of a library
subprogram.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>If a <FONT FACE="Arial, Helvetica">library_unit_body</FONT> that is a <FONT FACE="Arial, Helvetica">subprogram_body</FONT> is submitted to the
compiler, it is interpreted only as a completion if a
<FONT FACE="Arial, Helvetica">library_unit_declaration</FONT> with the same <FONT FACE="Arial, Helvetica">defining_program_unit_name</FONT>
already exists in the environment for a subprogram other than an instance of
a generic subprogram or for a generic subprogram (even if the
profile of the body is not type conformant with that of the declaration);
otherwise the <FONT FACE="Arial, Helvetica">subprogram_body</FONT> is interpreted as both the declaration and
body of a library subprogram.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A library subprogram body never completes an existing generic instance,
but replaces it.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It is a general principle in Ada 95 (as in Ada 83) that a library generic
instance be considered as a single lump and can not be considered
decomposed into specification and body for the purposes of completion or
replacement.
</P>
<P>Suppose we compile
</P>
<PRE><TT><UL><B>generic</B> <B>procedure</B> GP;
</UL></TT></PRE>
<PRE><TT><UL><B>procedure</B> GP <B>is</B> ... <B>end</B> GP;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> GP;
<B>procedure</B> P <B>is</B> <B>new</B> GP;
</UL></TT></PRE>
<P>and then submit
</P>
<PRE><TT><UL><B>procedure</B> P <B>is</B>
<B>begin</B> ... <B>end</B> P;
</UL></TT></PRE>
<P>The consequence is that the newly submitted procedure P completely
replaces the instance P. It does not act as a new completion for the
instance specification and thereby just replace the notional body of the
instance.
</P>
<P>However, this intention was not clear in the Ada 83 standard but was clarified
by AI83-199 and AI83-266. In particular, the latter says
</P>
<P>&quot;After instantiating a generic subprogram as a library unit, any attempt
to compile a subprogram body having the same identifier as that of the
library unit instantiation causes the instantiation to be deleted from
the library and replaced with the new library unit subprogram.&quot;
</P>
<P>It was the intention that the behaviour in Ada 95 be the same in this
respect. However, there was a change of wording between Ada 83 and
Ada 95 which might have been the source of confusion. In Ada 83 the term
subprogram did not include an instance whereas in Ada 95 the term
subprogram does include an instance.
</P>
<P>In the Ada 95 standard, 10.1.4(4) says
</P>
<P>&quot;If a library_unit_body that is a subprogram_body is submitted to the
compiler, it is interpreted only as a completion if a
library_unit_declaration for a subprogram or a generic subprogram with
the same defining_program_unit_name already exists in the environment ... &quot;
</P>
<P>This incorrectly uses the term &quot;subprogram&quot; where it intended to exclude
the case of an instance and so should have said &quot;a subprogram that is not
an instance&quot;.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0033"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0033 -  Placement of program unit pragmas in generic packages</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00136<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 10.1.5</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider:
</P>
<PRE><TT><UL><B>generic</B>
  <B>pragma</B> Pure; -- (a)  Legal? (No.)
  <B>type</B> F <B>is</B> . . .
<B>package</B> G <B>is</B>
  <B>pragma</B> Pure; -- (b)  Legal? (Yes.)
  <B>type</B> T <B>is</B> . . .
<B>end</B> G;
</UL></TT></PRE>
<P>10.1.5(5) says the pragma shall appear:
</P>
<P><UL>Immediately within the declaration of a program unit and before
any nested declaration, in which case the argument, if any, shall
be a direct_name that denotes the immediately enclosing program
unit declaration.
</UL></P>
<P>This seems to imply that the pragma Pure belongs at (a), and not at (b).
Is this the intent?  (No.)
</P>
<P>Consider also:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    -- No declarations here.
<B>private</B>
    <B>pragma</B> Pure; -- Legal? (No.)
<B>end</B> P;
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A program unit pragma for a generic package must appear at the beginning
of the package specification, and not in the generic formal part.  For
any program unit, such a pragma must not appear in the private part.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  10.1.5(5):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>

Immediately within the declaration of a program unit and before
any nested declaration, in which case the argument, if any, shall
be a <FONT FACE="Arial, Helvetica">direct_name</FONT> that denotes the immediately enclosing program
unit declaration.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>

Immediately within the visible part of a program
unit and before any nested declaration (but not within a generic
formal part), in which case the argument, if any, shall be a
<FONT FACE="Arial, Helvetica">direct_name</FONT> that denotes the immediately enclosing program unit
declaration.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It was not the intent to allow or require a program unit pragma for a
generic package at the beginning of the generic formal part.
Furthermore, such a placement would be strange and confusing.  Thus, the
wording of 10.1.5(5) is incorrect in this case.
</P>
<P>Likewise, it was not the intent to allow placement within a private
part, just because there happen to be no declarations in the visible
part.  Allowing that would introduce a small but pointless
implementation burden, and would be confusing, since Pure and so forth
represent externally visible properties of program units.
</P>
<P>Note that for a generic unit, the term &quot;visible part&quot; officially
includes the generic formal part.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0034"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0034 -  Program unit pragmas in generic units</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00041<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 10.1.5</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Do program unit pragmas and in particular library unit pragmas within a
generic unit and referring to the generic unit apply to all instances of the
generic unit?
</P>
<P>Consider:
</P>
<PRE><TT><UL><B>generic</B>
    ...
<B>package</B> P <B>is</B>
    <B>pragma</B> Pure(P);
 ...
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> PI <B>is</B> <B>new</B> P(...);
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
    ...
<B>package</B> Q <B>is</B>
    <B>pragma</B> Pure;
 ...
<B>end</B> Q;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> QI <B>is</B> <B>new</B> Q(...);
</UL></TT></PRE>
<P>Does the pragma Pure apply to the respective instances PI and QI? (No.)
</P>
<P>Since pragma Pure is a library unit pragma, are instantiations of P and Q
illegal, if the resulting instances are not library units? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Library unit pragmas within a generic unit and applying to the generic
unit itself do not apply to instances of the generic unit, unless a
specific rule of the pragma specifies the contrary.
</P>
<P>If the user wants a library unit pragma without such a rule to apply to
an instance, then that pragma must be repeated explicitly for the
instance.
</P>
<P>The following Implementation Advice is added:
Program unit pragmas that are not library-unit pragmas, when
supported for a generic unit, should apply to all instances of the
generic for which there is not an overriding pragma applied directly
to the instance.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  10.1.5(7):   </FONT></B></P>
<UL><P>Certain program unit pragmas are defined to be <I>library unit pragmas</I>. The
name, if any, in a library unit pragma shall denote the declaration of a
library unit.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><P><I><FONT SIZE=-2>Static Semantics</FONT></I>
</P></UL>
<UL><P>A library unit pragma that applies to a generic unit does not apply to its
instances, unless a specific rule for the pragma specifies the contrary.
</P></UL>
<UL><P><I><FONT SIZE=-2>Implementation Advice</FONT></I>
</P></UL>
<UL><P>When applied to a generic unit, a program unit pragma that is not a library unit
pragma should apply to each instance of the generic unit for which there is not
an overriding pragma applied directly to the instance.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Library unit pragmas within a generic unit and applying to the generic unit
itself do not apply to instances of the generic unit, unless a specific
semantic rule of the pragma specifies the contrary.
</P>
<P>If the user wants such a pragma to apply to an instance, then it must be
repeated explicitly for the instance.
</P>
<P>The program unit pragma INLINE applies to all instances, based on an
explicit semantic rule of the pragma. Since a ruling on the applicability
of program unit pragmas affects only implementation-defined support of
pragmas, an implementation advice should be added in 10.1.5 that, for
program unit pragmas applied to generic units, the pragma should apply
to all instances of the generic unit.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>An exegesis of the standard showed that a clear answer to the questions
cannot be derived from it. This exegesis is not reproduced for the
Defect Report, but can be retrieved from the appendix of the working document
AI-00041.
</P>
<P>An examination of the individual program unit pragmas follows.
</P>
<P>Some general observations:
</P>
<P><UL>1. If a pragma that applies to a generic unit were not to apply
to all instances, the user would still have the option to
specify such a pragma for each of the instances individually.
This may be cumbersome, but no language functionality is lost.
</UL></P>
<P><UL>2. If a pragma that applies to a generic unit were to apply to
all instances automatically, the user would lose the
capability of specifying a pragma that applies to the generic
unit only.
Note that the user does not have the option of placing the
pragma outside the generic package and thereby escape a
&quot;current instance rule&quot; (discussed later) selectively, since
such placement is not allowed for pragmas on generic packages
(see 10.1.5(4)).
</UL></P>
<P>We now examine the pragma semantics for all program unit pragmas
and discuss whether or not the pragma should apply to the generic unit
only or to all its instances as well.
</P>
<P>Pragma Preelaborate:
</P>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>with</B> user_defined_function;
<B>generic</B>
   ...
<B>package</B> P <B>is</B>
   <B>pragma</B> Preelaborate;
   X: integer := user_defined_function;
   ...
<B>end</B> P;
</UL></TT></PRE>
<P>The generic unit is legal, since its elaboration does not call the imported
function. (The purpose of the pragma is merely to ensure that the
elaboration of the generic body occurs prior to the elaboration of all
non-preelaborated library units; i.e., to avoid the need for elaboration
checks upon instantiations).
</P>
<P>Yet, if the pragma applies to the instances as well, they would all
be illegal, since they are not preelaborable !
</P>
<P>The semantics of pragma Preelaborate can been regarded as an expression of
intent that the pragma not be automatically applicable to all instances.
Otherwise the pragma should have enforced its restrictions on the nested
declarations within the generic package to detect the above problem prior
to any instantiation.
</P>
<P>If pragma Preelaborate applied to all instances, the user would no longer
have the means to force preelaboration of the body of the generic unit (as
shown in the example) without also imposing such preelaboration requirements
on all instances and restricting the instantiations to library level. (The
semantics of the pragma when applied to local instances is somewhat
ill-defined.)
</P>
<P>We conclude that pragma Preelaborate should not automatically apply to all
instances of the generic unit.
</P>
<P>Pragma Pure:
</P>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>generic</B>
   <B>type</B> T <B>is</B> <B>private</B>;
<B>package</B> Q <B>is</B>
   <B>pragma</B> Pure(Q);
   <B>type</B> TN <B>is</B> <B>new</B> T;
   ...
<B>end</B> Q;
</UL></TT></PRE>
<P>The user intention of pragma Pure in this package is to indicate that this
generic unit can (but need not) be instantiated to yield a pure
package. E.g.:
</P>
<PRE><TT><UL><B>type</B> Acc <B>is</B> <B>access</B> TT;
<B>package</B> Q_Acc <B>is</B> <B>new</B> Q(Acc);  -- not a pure package
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> Q_Int <B>is</B> <B>new</B> Q(Integer); -- a pure package
<B>pragma</B> Pure(Q_Int);
</UL></TT></PRE>
<P>If the pragma were applicable to all instances, the package Q_Acc would be
illegal.
</P>
<P>This would put the writer of reusable generic packages that satisfy the
necessary conditions for pure instances into a serious dilemma: If the
pragma Pure is inserted, the reusability is curtailed to pure instances
only. If the pragma Pure is not inserted, reusability is curtailed, because
instances can then not be pure, since the purity rules prohibit the
necessary dependency on the generic unit.
</P>
<P>This reuse problem arises not only from the nature of the actual parameters
of the instantiation, but also (and more importantly) from the context
clauses of the instantiation, i.e.,
</P>
<PRE><TT><UL><B>with</B> P;  -- P not pure
<B>package</B> Q_Int2 <B>is</B> <B>new</B> Q(P.T);  -- would be illegal irrespective
                               -- of the nature of P.T
</UL></TT></PRE>
<P>and from any non-pure context of a local instantiation (if local instances
were allowed at all, given that the pragma is a library unit pragma).
</P>
<P>Among others, any predefined or implementation-defined pure generic packages
could not be instantiated in any non-pure context, which would be a quite
devastating consequence.
</P>
<P>(A similar dilemma arises for all the other categorization pragmas when
used (or not used) in reusable generic packages.)
</P>
<P>We conclude that pragma Pure definitely should not automatically apply to
all instances of the generic unit.
</P>
<P>Pragmas Shared_Passive and Remote_Types:
</P>
<P>These pragmas impose the necessary restrictions to create a shared passive
or a remote types library unit, respectively.  As in the case of pragma
Pure, such a pragma for a generic unit is a precondition for any
instantiation to be so classified.  However, unlike pragma Pure, it is not
quite as obvious why instances should not be automatically in the respective
category as well.
</P>
<P>In the case of shared passive packages there is a potential issue when
an application may be required to execute in environments that may or
may not support storage nodes. If an instantiation is shared passive
then the library unit may only be assigned to a single partition. In
environments that do not support storage nodes this may be unnecessarily
restrictive since it is possible that a non-categorized instance can be
replicated in different partitions without compromising execution (e.g.,
if there are no variables in the package specification since a typical
use of shared passive packages may be to store constant data that are
common to different partitions).
</P>
<P>In the case of remote types packages, one may wish to declare a type with
subprograms that may be accessed both locally and remotely depending upon
the instantiation. If the pragma applies to all instantiations then, when
any declared access type within the package is referenced, it must be
treated as containing a potentially remote access value. (This is
particularly relevant, if the implementation uses wide pointers to represent
remote access type values.)
</P>
<P>One might perhaps surmise that despite the above scenarios, user convenience
might argue for automatically applying these pragmas to all instances. However,
we observe that no semantic difficulties arise if this were not the case and
that such implicit &quot;inheritance&quot; seems contrary to the principle that
critical specifications should be explicit. The cited situations show that
to a-priori preclude that reusable packages can be instantiated both in
restricted and unrestricted contexts may be unwise.
</P>
<P>Pragma All_Calls_Remote, Remote_Call_Interface:
</P>
<P>It is not unreasonable for applications to develop generic packages that may
be instantiated to provide both locally and remotely accessible
subprograms. For example, consider the case of a partition that provides the
same interface for both intra-partition and inter-partition clients.  If an
instantiation is always a remote interface package, then intra-partition
clients will incur the cost of calling subprograms through a compiler
generated stub.
</P>
<P>Additionally, a confirmation of the intent that this pragma should be
explicitly specified is present in AARM E.2.3(15.b) where it is stated, &quot;We
considered making the public child of an RCI package implicitly RCI, but it
seemed better to require an explicit pragma to avoid any confusion.&quot; It
seems inconsistent to require an explicit pragma for a public child and not
require an explicit pragma for an instantiation.
</P>
<P>We conclude that the pragma should be applicable to the generic unit only.
</P>
<P>Pragma Elaborate_Body:
</P>
<P>Pragma Elaborate_Body applied to generic library unit forces the elaboration
of the body of the unit immediately after the elaboration of the generic
declaration.  In the case of instantiations, this effect of the pragma
merely restates the existing rules on instance elaboration, 12.3(20), so
that this effect is the rule for instantiations in general. Hence, there is
no need to make the pragma apply automatically to all instances, while it
would be most detrimental to enforce as a secondary consequence that such
instantiations yield only library units.
</P>
<P>We conclude that the pragma should be applicable to the generic unit only.
</P>
<P>Pragmas Elaborate and Elaborate_All:
</P>
<P>These pragmas are irrelevant for this discussion, as they refer to program
units other than the (generic) unit in which they appear. (Consequently, the
affected units are elaborated prior to the elaboration of the generic unit
and, hence, its instances.)
</P>
<P>Pragma Inline:
</P>
<P>Pragma Inline (historically) subscribes to the rule that it applies to all
instances, when given for a generic subprogram.  Its application to all
instances relies on explicitly stated semantics of the pragma given in 6.3.2(5).
</P>
<P>Pragmas Convention, Export, Import:
</P>
<P>The applicability of these program unit pragmas to generic units is left
implementation-defined by this International Standard. Thus, implementations
can choose
whichever semantics seem most appropriate. Since these pragmas are not
library unit pragmas, inheritance of the pragma by instances of the generic
unit does not have the detrimental effects shown earlier in this analysis.
In fact, if the pragmas were to apply only to the generic unit and not to its
instances, it would be difficult to associate any semantics with them. The
most natural interpretation is therefore that the pragmas apply to all
instances of the generic unit.
</P>
<P>This concludes the list of predefined program unit pragmas. We have seen
that, in some cases, applicability of the pragma to all instances would be
seriously detrimental. We have seen other cases of library unit pragmas,
where applicability to all instances may be more convenient on occasion, but
is neither absolutely necessary nor warrants a rule that <I>a priori</I> precludes
reusable generic units that can be instantiated in both restricted and unrestricted
contexts.
</P>
<P>Finally, we have seen that the existing language-defined program unit pragmas
that are not library unit pragmas should apply to their instances. For the Inline
pragma, this rule is already explicitly stated. However, as this presently matters
only in cases, where applicability of the pragma to generic units is
implementation-defined, and one can equally well conceive of future
language-defined or implementation-defined pragmas, where automatic
applicability to instances would not be appropriate, it was decided to make
such an inheritance of pragmas by instances merely implementation advice, not
a general semantic rule.
</P>
<P>Although a program unit pragma on a generic should then generally be
&quot;inherited&quot; by its instances, it might be overridden by a pragma applied
directly to the instance, e.g., by a Convention or Export pragma.  This is
analogous to the rule for inheriting representation items by a derived type
from its parent type.  The inherited specification may be overridden
by a direct specification on the derived type itself.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0035"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0035 -  Subunits of a preelaborated subprogram</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00002<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 10.2.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>10.2.1(11) says, &quot;All compilation units of a preelaborated library unit
shall be preelaborable.&quot;  The term &quot;all compilation units&quot; includes
subunits.  Is this really intended? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A subunit which is not elaborated as part of elaborating a preelaborated
library unit need not be preelaborable.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  10.2.1(11):   </FONT></B></P>
<UL><P>If a <FONT FACE="Arial, Helvetica">pragma</FONT> Preelaborate (or <FONT FACE="Arial, Helvetica">pragma</FONT> Pure -- see below) applies to a
library unit, then it is <I>preelaborated</I>. If a library unit is preelaborated,
then its declaration, if any, and body, if any, are elaborated prior to all
non-preelaborated <FONT FACE="Arial, Helvetica">library_item</FONT>s of the partition. All compilation units of a
preelaborated library unit shall be preelaborable. In addition to the places
where Legality Rules normally apply (see 12.3), this rule applies also in the
private part of an instance of a generic unit. In addition, all compilation
units of a preelaborated library unit shall depend semantically only on
compilation units of other preelaborated library units.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>If a <FONT FACE="Arial, Helvetica">pragma</FONT> Preelaborate (or <FONT FACE="Arial, Helvetica">pragma</FONT> Pure -- see below) applies to a
library unit, then it is <I>preelaborated</I>. If a library unit is preelaborated,
then its declaration, if any, and body, if any, are elaborated prior to all
non-preelaborated <FONT FACE="Arial, Helvetica">library_item</FONT>s of the partition. The declaration and body
of a preelaborated library unit, and all subunits that are elaborated as part of
elaborating the library unit, shall be preelaborable. In addition to the places
where Legality Rules normally apply (see 12.3), this rule applies also in the
private part of an instance of a generic unit. In addition, all compilation
units of a preelaborated library unit shall depend semantically only on
compilation units of other preelaborated library units.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It is unnecessary to require a subunit of a preelaborated subprogram to
be preelaborable, because such a subunit is not elaborated during
elaboration of the subprogram. This also applies to subunits of preelaborated
tasks and any other unit which does not elaborate its contents when it is
elaborated.
</P>
<P>Furthermore, subunits and physically nested program units should behave
in the same way.  If a subprogram is preelaborated, packages physically
nested within the subprogram need not be preelaborable; therefore, the
same should be true of package subunits.
</P>
<P>Note that a subunit of a preelaborated package is required to be
preelaborable even without the quoted sentence, because such a subunit
is elaborated during elaboration of the parent package, and the
definition of preelaborability in 10.2.1(5) says, &quot;... unless its
elaboration performs...&quot;, which makes the rule transitive.
</P>
<P>The proposed change to the rule makes it always the case that subunits and
physically nested program units behave the same, even in the face of nesting
or multiple levels of subunits.
</P>
<P>Note that the rule is irrelevant for subunits that are subprograms,
since subprograms are always preelaborable. But it is relevant for package
and other subunits.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0036"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0036 -  Access_Check is performed for access discriminants</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00176<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 11.5</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Is the null check that occurs when evaluating a discriminant association
for an access discriminant considered to be an Access_Check? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The check that an access discriminant is non-null is an Access_Check.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  11.5(11):   </FONT></B></P>
<P><UL><DL>
<DT>Access_Check<DD>
When evaluating a dereference (explicit or
implicit), check that the value of the <FONT FACE="Arial, Helvetica">name</FONT> is
not <B>null</B>. When passing an actual parameter to a
formal access parameter, check that the value of
the actual parameter is not <B>null</B>.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>Access_Check<DD>
When evaluating a dereference (explicit or
implicit), check that the value of the <FONT FACE="Arial, Helvetica">name</FONT> is
not <B>null</B>. When passing an actual parameter to a
formal access parameter, check that the value of
the actual parameter is not <B>null</B>. When evaluating a
<FONT FACE="Arial, Helvetica">discriminant_association</FONT> for an access discriminant,
check that the value of the discriminant is not <B>null</B>.</DL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It was an oversight to omit the null check that occurs on discriminant
association for an access discriminant from the list of checks associated
with Access_Check in 11.5(11).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0037"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0037 -  Predefined operators for generic formal array types</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00043<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 12.5</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>There is an inconsistency between paragraphs 7.3.1(3) and 12.5(8)
regarding predefined operators for formal array types in some rare
cases. The former says that additional predefined operators may be
declared when additional characteristics of the component type become
known, whereas 12.5(8) says that all predefined operators are declared
immediately after the formal type declaration.
</P>
<P>Example:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
   <B>pragma</B> Elaborate_Body;   -- just to make its body legal
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> Pt <B>is</B> <B>private</B>;
</UL></TT></PRE>
<PRE><TT><UL>   <B>generic</B>
      <B>type</B> Ft <B>is</B> <B>array</B>( 1 .. 9 ) <B>of</B> Pt;
   <B>package</B> G <B>is</B>
   <B>end</B> G;
</UL></TT></PRE>
<PRE><TT><UL><B>private</B>
   <B>type</B> Pt <B>is</B> <B>new</B> Boolean;
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> P <B>is</B>
</UL></TT></PRE>
<PRE><TT><UL>   <B>package</B> <B>body</B> G <B>is</B>
      -- relational operators declared for Ft here? (Yes.)
      -- 12.5(8) says no, 7.3.1(3) says yes
   <B>end</B> G;
</UL></TT></PRE>
<PRE><TT><UL><B>end</B> P;
</UL></TT></PRE>
<P>(A similar example could be made using a public generic child unit to P, in
which case the relational operators would be declared when entering the
private part of the public child).
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For a generic formal type whose properties depend on a partial view
(for example, a formal array type whose component type is a private type)
the rules of 7.3.1 apply.  Thus, the primitive subprograms of the formal
type are not necessarily declared immediately after its declaration.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  12.5(8):   </FONT></B></P>
<UL><P>The formal type also belongs to each class that contains the determined
class. The primitive subprograms of the type are as for any type in the
determined class. For a formal type other than a formal derived type, these
are the predefined operators of the type; they are implicitly declared
immediately after the declaration of the formal type. In an instance, the
copy of such an implicit declaration declares a view of the predefined
operator of the actual type, even if this operator has been overridden for
the actual type. The rules specific to formal derived types are given in
12.5.1.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The formal type also belongs to each class that contains the determined class.
The primitive subprograms of the type are as for any type in the determined
class. For a formal type other than a formal derived type, these are the
predefined operators of the type. For an elementary formal type, the predefined
operators are implicitly declared immediately after the declaration of the
formal type. For a composite formal type, the predefined operators are
implicitly declared either immediately after the declaration of the formal type,
or later in its immediate scope according to the rules of 7.3.1. In an instance,
the copy of such an implicit declaration declares a view of the predefined
operator of the actual type, even if this operator has been overridden for the
actual type. The rules specific to formal derived types are given in 12.5.1.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>For a generic formal type whose properties depend on a partial view
(for example, a formal array type whose component type is a private type)
the rules of 7.3.1 apply.  Thus, the primitive subprograms of the formal
type are not necessarily declared immediately after its declaration.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>7.3.1(3) and 12.5(8) are in conflict for generic formal types.
7.3.1(3) should take precedence, since otherwise the privacy of
private types would be violated.  Furthermore, this interpretation
is compatible with Ada 83.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0038"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0038 -  Primitives of formal type derived from another formal type</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00202<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 12.5.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>In an instance of a generic with a formal derived type whose ancestor type
is another formal type, the rules regarding the meanings of the implicit
declarations for the formal derived type produce a peculiar result.
</P>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>package</B> P1 <B>is</B>
   <B>type</B> R1 <B>is</B> <B>record</B> ... <B>end</B> <B>record</B>;
   <B>procedure</B> S (x : R1);                  -- [1]
<B>end</B> P1;
<B>use</B> P1;
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
   <B>type</B> F2 <B>is</B> <B>new</B> R1;
   -- implicit: procedure S (x : F2);     -- [2]
   <B>type</B> F3 <B>is</B> <B>new</B> F2;
   -- implicit: procedure S (x : F3);     -- [3]
<B>procedure</B> G (o2 : F2; o3 : F3);
<B>procedure</B> G (o2 : F2; o3 : F3) <B>is</B>
<B>begin</B>
   S(o2);
   S(o3);        -- Peculiar result: Calls S [5] in instance I?  (No.)
<B>end</B> G;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> P2 <B>is</B>
   <B>type</B> R2 <B>is</B> <B>new</B> R1;
   -- implicit: procedure S (x : R2);     -- [4]
   <B>procedure</B> S (x : <B>out</B> R2);              -- [5] Overriding with mode out
<B>end</B> P2;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> P3 <B>is</B>
   <B>type</B> R3 <B>is</B> <B>new</B> P2.R2;
   -- implicit: procedure S (x : R3);     -- [6]
   <B>procedure</B> S (x : R3);                  -- [7]
<B>end</B> P3;
</UL></TT></PRE>
<PRE><TT><UL><B>procedure</B> I <B>is</B> <B>new</B> G (P2.R2, P3.R3);
</UL></TT></PRE>
<P>In the instance I, the implicit declarations of S which operate on F2 and F3,
respectively, are the corresponding primitive subprograms of the ancestor
types of each type, as stated in 12.5.1(21).  The ancestor type of F2 is
R1, so the implicit declaration of S that operates on F2 [2] is a view of the
corresponding primitive subprogram of R1 [1].
</P>
<P>The ancestor type of F3 is the type of the subtype denoted by the name F2 in
the instance, which is R2.  So, the implicit declaration of S that operates
on F3 [3] is a view of the corresponding primitive subprogram of R2 [5].
But, the annotation in AARM 12.5.1(21.a) indicates that the reason the
primitives of a formal derived type in an instance are views of its
ancestor's primitives is because the primitives of its actual type might not
be subtype conformant with those of its ancestor type.  This intention could
be violated if the primitive S [3] is a view of the primitive S [5].
</P>
<P>Is it the intent that the primitive S [3] should declare a view of S [1]?
(Yes.)
</P>
<P>In general, when the ancestor type of a formal derived type is itself
another formal type, then within an instance does the derived type
acquire the primitive operations of the formal ancestor type or the
primitive operations of the ancestor type's corresponding actual type?
(The primitive operations of the formal ancestor.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>In an instance of a generic unit having a formal derived type whose ancestor
is itself a formal type, the copies of the implicit subprogram declarations
of the formal derived type declare views of the corresponding copies of the
primitive subprograms of the formal ancestor type.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  12.5.1(21):   </FONT></B></P>
<UL><P>For a formal derived type, the predefined operators and inherited
user-defined subprograms are determined by the ancestor type, and are
implicitly declared at the earliest place, if any, within the immediate scope
of the formal type, where the corresponding primitive subprogram of the
ancestor is visible (see 7.3.1). In an instance, the copy of such an
implicit declaration declares a view of the corresponding primitive
subprogram of the ancestor, even if this primitive has been overridden for
the actual type. In the case of a formal private extension, however, the tag
of the formal type is that of the actual type, so if the tag in a call is
statically determined to be that of the formal type, the body executed will
be that corresponding to the actual type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For a formal derived type, the predefined operators and inherited user-defined
subprograms are determined by the ancestor type, and are implicitly declared at
the earliest place, if any, within the immediate scope of the formal type, where
the corresponding primitive subprogram of the ancestor is visible (see 7.3.1).
In an instance, the copy of such an implicit declaration declares a view of the
corresponding primitive subprogram of the ancestor of the formal derived type,
even if this primitive has been overridden for the actual type. When the
ancestor of the formal derived type is itself a formal type, the copy of the
implicit declaration declares a view of the corresponding copied operation of
the ancestor. In the case of a formal private extension, however, the tag of the
formal type is that of the actual type, so if the tag in a call is statically
determined to be that of the formal type, the body executed will be that
corresponding to the actual type.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The copies of the implicitly declared primitive subprograms of a formal
derived type in an instance are defined to be views of the ancestor type's
corresponding operations (12.5.1(21)).  In the case of a formal type whose
ancestor is another formal type of the same generic unit, this results
in the undesirable semantics that in an instance, the copies of the first
formal type's implicitly declared operations are views of the corresponding
operations of the ancestor type's actual type.
</P>
<P>It is essential to ensure that such copied implicit operations are always
views of some ancestor known at the point of the generic formal type's
declaration, since using the operations of the formal ancestor's actual
type can lead to inconsistencies because the operations of an actual
(untagged) type may not be subtype conformant with those of the formal type.
</P>
<P>The rule of 12.5.1(21) is amended to correct this problem.  The copies
of a formal derived type's operations in an instance are defined to be
views of the corresponding copies of the primitive operations of the
formal type's ancestor when the ancestor is a formal type, rather than
simply those of &quot;the ancestor type&quot; (which in an instance would denote
the actual type associated with the formal type's ancestor).
</P>
<P>Note that in the case where the formal ancestor type is a formal derived
type, the copied operations of the ancestor type in the instance are
themselves views of operations coming from the ancestor type's own ancestor
(so the new rule applies transitively for arbitrary levels of derivation
from formal derived types).
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>12.5.1(21) defines the implicit operations that are declared
for a formal derived type, as well as the meaning of the copies of those
implicit operations declared within an instance.  The second sentence
states:
</P>
<P><UL>In an instance, the copy of such an implicit declaration declares
a view of the corresponding primitive subprogram of the ancestor,
even if this primitive has been overridden for the actual type.
</UL></P>
<P>However, in the instance of a generic unit with formal derived type T2
whose ancestor type is itself a formal derived type T1, the phrase
&quot;of the ancestor&quot; must be interpreted as referring to the actual
type A1 associated with the formal ancestor T1.  This is because
in the instance, the ancestor type of the copy of T2 is a view of the
actual type A1 associated with T1.  This is the normal interpretation
of copies of declarations within instances as defined by the static
semantics in 12.3(13-16).  But that leads to the conclusion that the
view defined in 12.5.1(21) denotes the corresponding primitive
subprogram of the ancestor's actual type.
</P>
<P>As shown in the example of the question section, this can result
in inconsistent views of a formal type's primitive operations,
since the formal view of a primitive may not be subtype conformant
with the view in an instance.  For example, modes of parameters may
differ between the formal and actual views of an subprogram, leading
to undefined semantics for the copied version of a call to such
a subprogram from within an instance.  This would essentially
result in a generic contract model violation in the body of the
instance.
</P>
<P>The Ramification in AARM-12.5.1(21.a) makes the intent behind 12.5.1(21)
clear, explaining how in the case of untagged types the rule ensures that
the operations of the type in an instance are those of the ancestor rather
than those of the actual type, which may not be subtype conformant.
However the formulation of the rule does not account for cases where the
ancestor is a formal type itself, whose operations may not be subtype
conformant with those of a corresponding actual type in an instance.
</P>
<P>This problem is fixed by specifying that, in an instance, the
implicit declaration of a primitive subprogram of a formal derived
type with a formal ancestor declares a view of the corresponding
copied operation of the ancestor.
</P>
<P>If the ancestor is a nonderived formal type, then the copied operations
of the ancestor declare views of the predefined operators of the ancestor's
corresponding actual type.
</P>
<P>In the case where the ancestor is itself a formal derived type, then
the copied operations of the ancestor will themselves be views of
operations coming from the ancestor type's own ancestor, so the rule
applies transitively for arbitrary levels of derivation from formal
derived types.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0039"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0039 -  Formal object matching for formal packages</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00213<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 12.7</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>For a generic formal object of mode in, the rule in 12.7(6) defines
a matching rule for actuals of generic formal packages. If the type of
such an object is a type which cannot have static expressions (such as a
tagged type), can the actuals ever match? (Yes.)
</P>
<P>An actual for an instance denotes a new stand-alone constant
initialized by the actual to the instantiation, as described in
12.4(10). Therefore, the actuals for a formal package can never statically
denote the same constant. Is this correct? (No.)
</P>
<P>Here is an example:
</P>
<PRE><TT><UL><B>package</B> Pack <B>is</B>
  <B>type</B> Count_Type <B>is</B> <B>tagged</B> <B>record</B>;
    Count : Integer := 0;
  <B>end</B> <B>record</B>;
</UL></TT></PRE>
<PRE><TT><UL>  TC_Default_Count : <B>constant</B> Count_Type := (Count =&gt; 0);
<B>end</B> Pack;
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
  <B>type</B> Item (&lt;&gt;) <B>is</B> <B>tagged</B> <B>private</B>;
  TC_Default_Value : Item;
<B>package</B> Test_0 <B>is</B>
...
<B>end</B> Test_0;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Test_0;
<B>generic</B>
  <B>type</B> Item_Type (&lt;&gt;) <B>is</B> <B>tagged</B> <B>private</B>;
  Default : Item_Type;
  <B>with</B> <B>package</B> Stacker <B>is</B> <B>new</B> Test_0 (Item_Type, Default);
<B>procedure</B> Test_1 (S : <B>in</B> <B>out</B> Stacker.Stack; I : <B>in</B> Item_Type);
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Pack;
<B>with</B> Test_0;
<B>pragma</B> Elaborate (Test_0);
<B>package</B> Test_2 <B>is</B> <B>new</B> Test_0 (Pack.Count_Type,
  Pack.TC_Default_Count);
</UL></TT></PRE>
<PRE><TT><UL><B>procedure</B> Test <B>is</B>
  <B>package</B> Count_Stacks <B>renames</B> Test_2;
  <B>procedure</B> TC_Count_Test <B>is</B> <B>new</B> Test_1 (Pack.Count_Type,
            Pack.TC_Default_Count,Count_Stacks); -- Legal? (Yes.)
  ...
<B>end</B> Test;
</UL></TT></PRE>
<P>Note that Test_2.TC_Default_Value denotes a constant initialized by
Pack.TC_Default_Count, while TC_Count_Test.Default denotes
Pack.TC_Default_Count. Do these match by the rule of 12.7(6)? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For a generic formal object of mode in, the rule in 12.7(6) is applied
to the actual parameter of the actual instance, and the actual parameter for
the formal package. If the actual parameter for the formal package is itself
a formal parameter (of another generic unit), the actual for that parameter
is used for matching. The latter rule is applied recursively.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  12.7(8):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
For other kinds of formals, the actuals match if they statically
denote the same entity.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>For the purposes of matching, any actual parameter that is the name of a
formal object of mode <B>in</B> is replaced by the formal object's actual expression
(recursively).
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The intent of the standard is that actuals are always used for the matching
rule of 12.7(6). In addition, the intent is that formals denote the associated
actual for the purposes of the matching rule of 12.7(6).
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent of the standard is that actual objects are always used for the
matching rule of 12.7(6). In addition, the intent is that formal objects used
as actual parameters are ignored for the purposes of the matching rule of
12.7(6). Using formal objects as the actual parameter for a formal package
is a natural way to use formal packages. In addition, all existing Ada
compilers already support matching ignoring formal objects (as one of the
validation tests required this behavior).
</P>
<P>If the strict language in the standard was followed, this example would
be illegal. Indeed, any use of a formal object as an actual for a formal
object of mode in to a formal package would be illegal by 12.7(6). This
would require a substantial restructuring of formal packages if adding a
formal object was necessary. In some cases, no workaround is available.
In addition, existing code may depend on this feature, since compilers
have supported it for at least four years.
</P>
<P>The revised rule is written in terms of eliminating all formal objects
used directly as actuals, in order to avoid confusion. Other rules about
which formal objects are eliminated could be considered (only local objects,
only a single object, etc.) but these do not make the language easier to
implement, just more confusing for the user.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0040"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0040 -  Inheritance of stream attributes for type extensions</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00108<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.1;  13.3;  13.13.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>13.1(15) says:
</P>
<P><UL>A derived type inherits each type-related aspect of its parent type that
was directly specified before the declaration of the derived type, or (in the
case where the parent is derived) that was inherited by the parent type from
the grandparent type.  A derived subtype inherits each subtype-specific
aspect of its parent subtype that was directly specified before the
declaration of the derived type, or (in the case where the parent is derived)
that was inherited by the parent subtype from the grandparent subtype, but
only if the parent subtype statically matches the first subtype of the parent
type.  An inherited aspect of representation is overridden by a subsequent
representation item that specifies the same aspect of the type or subtype.
</UL></P>
<P>Do these rules apply to the stream-oriented attributes Read, Write,
Input, and Output?  (No.)
</P>
<P>If an untagged derived type includes a known discriminant part, the number of
discriminants can change. If we inherit the parent's attribute definition, we
could write the wrong number of discriminants. Consider:
</P>
<PRE><TT><UL><B>type</B> Parent (D1, D2 : Integer := 1) <B>is</B> ...;
<B>type</B> Child (D : Integer := 2) <B>is</B> <B>new</B> Parent (D1 =&gt; D, D2 =&gt; D);
</UL></TT></PRE>
<P>Clearly the default implementation of Parent'Write writes two discriminant
values.  How many discriminants does Child'Write write? (One.)
</P>
<P>Are the stream-oriented attributes intended to work properly for
language-defined types such as Unbounded_String?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For a type extension, the predefined Read attribute is defined to call
the Read of the parent type, followed by the Read of the non-inherited
components, if any, in canonical order.  The analogous rule applies to
the Write attribute.
</P>
<P>The Input and Output attributes are not inherited by a type extension.
</P>
<P>Default stream attributes are never inherited; rather, the default
implementation for the derived type is used.
</P>
<P>The stream attributes must work properly for every language-defined
nonlimited type.  For language-defined private types, the output
generated by the Write attribute is not specified, but it must be
readable by the Read attribute.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.1(15):   </FONT></B></P>
<UL><P>A derived type inherits each type-related aspect of its parent type that
was directly specified before the declaration of the derived type, or (in the
case where the parent is derived) that was inherited by the parent type from
the grandparent type. A derived subtype inherits each subtype-specific
aspect of its parent subtype that was directly specified before the
declaration of the derived type, or (in the case where the parent is derived)
that was inherited by the parent subtype from the grandparent subtype, but
only if the parent subtype statically matches the first subtype of the parent
type. An inherited aspect of representation is overridden by a subsequent
representation item that specifies the same aspect of the type or subtype.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A derived type inherits each type-related aspect of representation of its
parent type that was directly specified before the declaration of the derived
type, or (in the case where the parent is derived) that was inherited by the
parent type from the grandparent type. A derived subtype inherits each
subtype-specific aspect of representation of its parent subtype that was
directly specified before the declaration of the derived type, or (in the case
where the parent is derived) that was inherited by the parent subtype from the
grandparent subtype, but only if the parent subtype statically matches the
first subtype of the parent type. An inherited aspect of representation is
overridden by a subsequent representation item that specifies the same aspect
of the type or subtype.
</P></UL>
<UL><P>In contrast, whether operational aspects are inherited by a derived type
depends on each specific aspect. When operational aspects are inherited by a
derived type, aspects that were directly specified before the declaration of the
derived type, or (in the case where the parent is derived) that were inherited
by the parent type from the grandparent type are inherited. An inherited
operational aspect is overridden by a subsequent operational item that specifies
the same aspect of the type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.1(18):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
If an aspect of representation of an entity is not specified, it is
chosen by default in an unspecified manner.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>If an operational aspect is <I>specified</I> for an entity (meaning that it is
either directly specified or inherited), then that aspect of the entity is as
specified. Otherwise, the aspect of the entity has the default value for
that aspect.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.3(75):   </FONT></B></P>
<P><UL><DL>
<DT>S'External_Tag<DD>S'External_Tag denotes an external string
representation for S'Tag; it is of the predefined type String. External_Tag may be specified
for a specific tagged type via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>; the
expression of such a clause shall be static. The default external tag
representation is implementation defined. See 3.9.2 and 13.13.2.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>S'External_Tag<DD>S'External_Tag denotes an external string
representation for S'Tag; it is of the predefined type String. External_Tag may be specified
for a specific tagged type via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>; the
expression of such a clause shall be static. The default external tag
representation is implementation defined. See 3.9.2 and 13.13.2. The value
of External_Tag is never inherited; the default value is always used unless
a new value is directly specified for a type.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.13.2(9):   </FONT></B></P>
<UL><P>For elementary types, the representation in terms of stream elements is
implementation defined. For composite types, the Write or Read attribute for
each component is called in a canonical order. The canonical order of
components is last dimension varying fastest for an array, and positional
aggregate order for a record. Bounds are not included in the stream if <I>T</I> is
an array type. If <I>T</I> is a discriminated type, discriminants are included only
if they have defaults. If <I>T</I> is a tagged type, the tag is not included.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For untagged derived types, the Write and Read attributes of the parent type
are inherited as specified in 13.1; otherwise, the default implementations of
these attributes are used.
The default implementations of Write and Read attributes execute as follows:
</P></UL>
<UL><P>For elementary types, the representation in terms of stream elements is
implementation defined. For composite types, the Write or Read attribute for
each component is called in canonical order, which is
last dimension varying fastest for an array, and positional
aggregate order for a record. Bounds are not included in the stream if <I>T</I> is
an array type. If <I>T</I> is a discriminated type, discriminants are included only
if they have defaults. If <I>T</I> is a tagged type, the tag is not included.
For type extensions, the Write or Read attribute for the parent type
is called, followed by the Write or Read attribute of each component of the
extension part, in canonical order. For a limited type extension, if the
attribute of any ancestor type of <I>T</I> has been directly specified and the
attribute of any ancestor type of the type of any of the extension components
which are of a limited type has not been specified, the attribute of <I>T</I>
shall be directly specified.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.13.2(25):   </FONT></B></P>
<UL><P>Unless overridden by an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>, these subprograms
execute as follows:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For untagged derived types, the Output and Input attributes of the parent type
are inherited as specified in 13.1; otherwise, the default implementations of
these attributes are used. The default implementations of Output and Input
attributes execute as follows:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.13.2(36):   </FONT></B></P>
<UL><P>The stream-oriented attributes may be specified for any type via an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>. All nonlimited types have default
implementations for these operations. An <FONT FACE="Arial, Helvetica">attribute_reference</FONT> for one of
these attributes is illegal if the type is limited, unless the attribute
has been specified by an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>. For an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT> specifying one of these attributes, the
subtype of the Item parameter shall be the base subtype if scalar, and the
first subtype otherwise. The same rule applies to the result of the Input
function.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The stream-oriented attributes may be specified for any type via an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>. All nonlimited types have default
implementations for these operations. An <FONT FACE="Arial, Helvetica">attribute_reference</FONT> for one of
these attributes is illegal if the type is limited, unless the attribute
has been specified by an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT> or (for a type
extension) the attribute has been specified for an ancestor type. For an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT> specifying one of these attributes, the
subtype of the Item parameter shall be the base subtype if scalar, and the
first subtype otherwise. The same rule applies to the result of the Input
function.<BR>
<I><FONT SIZE=-2>Implementation Requirements</FONT></I><BR>
For every subtype S of a language-defined nonlimited specific type <I>T</I>, the
output generated by S'Output or S'Write shall be readable by S'Input or
S'Read, respectively. This rule applies across partitions if the implementation
conforms to the Distributed Systems Annex.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The general rule for inheritance of type-related representation aspects
should not apply to the stream attributes of type extensions.  For 'Read
and 'Write, a rule analogous to the rule for tagged equality makes the
most sense.  For 'Input and 'Output, no inheritance makes sense;
instead, they should regain their predefined meaning in terms of 'Read
and 'Write.
</P>
<P>There are several problems associated with applying the normal 13.1(15)
inheritance rules to the stream attributes of tagged types:
</P>
<P><UL>1) Inheriting a 'Read or 'Write of the parent type as-is for
the 'Read or 'Write of a type extension will ignore any new
components added in the extension part.  A rule analogous
to the one for the equality operator makes more sense.
In particular, the default 'Read or 'Write for a type extension
should be defined to do the 'Read or 'Write of the parent type
followed by the 'Read or 'Write for each component of the
type extension, in canonical order.
</UL></P>
<P><UL>2) Inheriting a 'Input or 'Output of the parent type as-is for
'Input or 'Output of a type extension makes no sense, since
the inherited 'Input is a function returning the parent type,
and the inherited 'Output puts out the discriminants of the
parent type.  For these two, the only meaningful approach seems
to be for the default 'Input and 'Output for a tagged type to
always be defined in terms of the 'Read and 'Write for the
tagged type, preceded with the discriminants, if any.
</UL></P>
<P>For untagged derived types, there is no (new) problem for the
derived type inheriting the stream attributes. Even for tagged derived
types, if the extension part is null, the 'Read and 'Write will
effectively be inherited.
</P>
<P>We must take care, however, that all of the components have the appropriate
attributes. For a limited type extension, the extension component could be
of a type that does not have an implementation of Write or Read. In that
case, we must take care to insure that the attribute for the new type does
handle the extension component. We do this by requiring an attribute
to be directly specified if it has a limited extension component that does
not have an implementation of Write or Read and the parent type has a
(specified) implementation of Write or Read. (An alternative would be to
inherit the original operation unmodified, but this would silently ignore
the extension components. This could cause hard-to-find bugs as the components
would probably revert to default values when they are input.) This rule is
similar to the way that functions of type extensions are inherited: they
aren't inherited, they must be overridden (except that we only invoke it
when we can't do the right thing automatically, which minimizes the places
where existing code becomes illegal).
</P>
<P>To see how this works in practice, consider the following example:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
   <B>type</B> T <B>is</B> <B>limited</B> <B>tagged</B> ...;
   <B>for</B> T'Read <B>use</B> ...;
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> Der <B>is</B> <B>new</B> T <B>with</B> <B>null</B> <B>record</B>;  --  OK (no extension components,
                                        --  T'Read is effectively inherited)
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> Der_Int <B>is</B> <B>new</B> T <B>with</B> -- OK (non-limited extension components,
                              --  T'Read is inherited with the additional
                              --  components added)
      <B>record</B>
         Int : Integer;
      <B>end</B> <B>record</B>;
</UL></TT></PRE>
<PRE><TT><UL>   <B>protected</B> <B>type</B> Protect_Type <B>is</B> ... -- Note: no 'Read specified.
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> Der_Protect_Type <B>is</B> <B>new</B> T <B>with</B> -- Illegal unless
                                 -- Der_Protect_Type'Read is specified;
                                 -- we can't compose T'Read, as
                                 -- Protect_Type'Read can't be called.
      <B>record</B>
         PT : Protect_Type;
      <B>end</B> <B>record</B>;
<B>end</B> P;
</UL></TT></PRE>
<P>Simply making the operation uncallable doesn't work, as the operations can be
dispatched. If, in the above example, Der_Protect_Type couldn't be called,
problems would arise if T'Class'Read was called on a Der_Protect_Type object.
</P>
<P>Clearly, the properties of the default implementation for the stream
attributes can change for derived types (as in the example given in
the question). Thus, we always want to use a &quot;fresh&quot; default
implementation for an attribute, rather than inheriting a default
implementation from the parent type.
</P>
<P>For language-defined nonlimited private types, the International Standard
does not say whether the stream-oriented attributes must work properly.
It seems that they ought to. For many such types, the default version will work
properly. However, for a type like Unbounded_String, which is almost
certainly implemented as a data structure involving access values, the
default versions will not work. Therefore, for these types, the
implementer must provide an explicit version of the Read and Write
attributes.
</P>
<P>The wording takes advantage of the newly defined &quot;operational attributes&quot;
(see 8652/0009 [AI-00137]) to say whether operational attributes are
inherited depends on the attribute. This simplifies the wording by
eliminating the need to describe a long list of exceptions to an inheritance
rule that we want only in some cases, and provides future flexibility.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0041"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0041 -  Incorrect syntax in example -- remove "limited"</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00066<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.11</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The syntax of the example 13.11(39) appears incorrect. Is it wrong? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The reserved word &quot;limited&quot; should be removed from the example in
13.11(39).
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.11(39):   </FONT></B></P>
<UL><UL><PRE><TT><B>type</B> Mark_Release_Pool_Type
    (Pool_Size : Storage_Elements.Storage_Count;
     Block_Size : Storage_Elements.Storage_Count)
         <B>is new</B> Root_Storage_Pool <B>with limited private</B>;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>type</B> Mark_Release_Pool_Type
    (Pool_Size : Storage_Elements.Storage_Count;
     Block_Size : Storage_Elements.Storage_Count)
         <B>is new</B> Root_Storage_Pool <B>with private</B>;</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This syntax was left from a previous draft of the standard.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0042"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0042 -  Enforcing Restrictions might violate the generic contract model</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00130<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.12;  D.7;  H.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>H.4(8) says:
</P>
<P><UL>No_Local_Allocators
</UL></P>
<P><UL><UL>Allocators are prohibited in subprograms, generic subprograms, tasks
and entry bodies; instantiations of generic packages are also
prohibited in these contexts.
</UL></UL></P>
<P>Why are instantiations prohibited in these contexts? (This ruling allows them.)
</P>
<P>The restrictions No_Task_Hierarchy and No_Nested_Finalization do not prohibit
such instantiations.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The enforcement of restrictions might violate the contract model
of generics, as well as violate the &quot;privateness&quot; of code in a private part
or body.
</P>
<P>To be consistent with the No_Task_Hierarchy and No_Nested_Finalization
restrictions, the No_Local_Allocators restriction should not preclude nested
generic instantiations.  No_Nested_Finalization is broadened to cover
finalization associated with protected and task objects.   For the purposes
of these (post-compilation) rules, a generic template is logically
expanded at the point of each instantiation, and all of the expressions of
the type definition for a record or protected type logically appear
at the point of any default-initialized object creation, and default parameter
expressions logically appear where used.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.12(8):   </FONT></B></P>
<UL><P>A <FONT FACE="Arial, Helvetica">pragma</FONT> Restrictions is a configuration pragma; unless otherwise
specified for a particular restriction, a partition shall obey the
restriction if a <FONT FACE="Arial, Helvetica">pragma</FONT> Restrictions applies to any compilation unit
included in the partition.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><P>For the purpose of checking whether a partition contains constructs
that violate any restriction (unless specified otherwise for a
particular restriction):
</P></UL>
<UL><UL><LI TYPE=DISC>
Generic instances are logically expanded at the point of instantiation;</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
If an object of a type is declared or allocated and not explicitly
initialized, then all expressions appearing in the definition for
the type and any of its ancestors are presumed to be used;</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
A <FONT FACE="Arial, Helvetica">default_expression</FONT> for a formal parameter or a generic formal
object is considered to be used if and only if the corresponding actual
parameter is not provided in a given call or instantiation.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.12(9):   </FONT></B></P>
<UL><P>An implementation may place limitations on the values of the <FONT FACE="Arial, Helvetica">expression</FONT>
that are supported, and limitations on the supported combinations of
restrictions. The consequences of violating such limitations are
implementation defined.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>An implementation is permitted to omit restriction checks for code that is
recognized at compile time to be unreachable and for which no code is generated.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.7(4):   </FONT></B></P>
<P><UL><DL>
<DT>No_Nested_Finalization<DD>Objects with controlled parts
and access types that designate such objects shall be declared only
at library level.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>No_Nested_Finalization<DD>Objects with controlled, protected,
or task parts, and access types that designate such objects, shall be
declared only at library level.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  H.4(8):   </FONT></B></P>
<P><UL><DL>
<DT>No_Local_Allocators<DD><FONT FACE="Arial, Helvetica">Allocator</FONT>s are prohibited in subprograms,
generic subprograms, tasks, and entry bodies; instantiations of generic
packages are also prohibited in these contexts.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>No_Local_Allocators<DD><FONT FACE="Arial, Helvetica">Allocator</FONT>s are prohibited in subprograms,
generic subprograms, tasks, and entry bodies.</DL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>An implementation supporting the No_Task_Hierarchy, No_Nested_Finalization, or
No_Local_Allocators restrictions must enforce the intent of these restrictions
with checks prior to run-time.
</P>
<P>For the purposes of these checks:
</P>
<P><UL>- Generic instances are logically expanded at the point of instantiation;
</UL></P>
<P><UL>- If an object of a type is declared or allocated and not explicitly
initialized, then all expressions appearing in the definition for
the type and any of its ancestors are presumed to be used.
</UL></P>
<P><UL>- Default formal parameters are presumed to be used only if the
corresponding actual parameter is not provided in a given call or
instantiation;
</UL></P>
<P><UL>- Notwithstanding the above, for code which is recognized at compile-time
as unreachable, and for which no object code is generated,
implementations are permitted to omit these checks.
</UL></P>
<P>No_Task_Hierarchy means that only tasks directly dependent on the master
representing the execution of the environment task (body) are permitted.
Tasks dependent on masters which correspond to other bodies or blocks are
not permitted, even if these masters are executed by the environment task.
</P>
<P>No_Nested_Finalization should be broadened to mean that objects
requiring finalization due to having a controlled, protected, or task
part are not permitted unless they are at the library level.
</P>
<P>No_Local_Allocators means that allocators are prohibited in subprograms,
generic subprograms, task bodies, and entry bodies.  As indicated above,
rather than precluding nested instantiations, instantiations are to be
logically expanded at the point of instantiation for the purposes
of this check.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Precluding nested generic instances for the No_Local_Allocators restriction
in H.4(8) in an attempt to preserve a generic contract model for restrictions
is inconsistent with the rules for No_Task_Hierarchy given in D.7(3) and
for No_Nested_Finalization given in D.7(4).  In general, enforcing
pragma Restrictions across a partition will necessarily violate the
&quot;privateness&quot; of a private part or a body, as well as the generic contract
model.
</P>
<P>Although it might be useful to know that if a generic body
does not by itself violate a restriction, then neither will any
instantiation, enforcing this kind of &quot;contract&quot; rule for restrictions
that distinguish library level from non-library level usages would
overly limit the nested instantiations of useful, benign generics.
Furthermore, the pragma Restrictions is primarily designed to
support application environments where schedulability
and formal verification requirements dictate that generics
can only be certified with respect to particular instantiations.
</P>
<P>A more serious problem with the rules given for the No_Task_Hierarchy
restriction in D.7(3), No_Nested_Finalization in D.7(4), and
No_Local_Allocators in H.4(8), is that they do not properly
account for violations appearing in expressions used for default
parameters and for default initialization.
</P>
<P>For example, the following partition obeys the static criteria given in H.4(8)
for the No_Local_Allocators restriction, yet (in the absence of code-removing
optimizations) the main subprogram evaluates an allocator:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
   <B>type</B> Integer_Pointer <B>is</B> <B>access</B> Integer;
   <B>type</B> R <B>is</B>
      <B>record</B>
         C: Integer_Pointer := <B>new</B> Integer;
      <B>end</B> <B>record</B>;
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> P;
<B>procedure</B> Main <B>is</B>
   X: P.R;  -- X.C is initialized by invoking an allocator
<B>begin</B>
   <B>null</B>;
<B>end</B> Main;
</UL></TT></PRE>
<P>To close such loopholes, it is necessary to logically substitute
default initialization and default parameters in line at the point
of usage.
</P>
<P>To ease the burden for implementations which check these restrictions
late in the compilation process or during linking, implementations are
permitted to omit the checks within constructs which generate no
object code, because they are recognized as unreachable.  Code
which presumes a given implementation takes advantage of this permission
is clearly less portable.
</P>
<P>For an implementation that shares code between generic instantiations,
it might be necessary for it to collect information while compiling a generic
body which would allow the implementation to determine at link-time
whether particular instantiations do or do not violate these
restrictions.  This is similar to other information gathering that
is required of all implementations as part of implementing the
Restrictions pragma, so this is not felt to be unduly burdensome.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0043"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0043 -  Compile-time enforcement of pragma Restrictions</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00190<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.12</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Shall we allow implementations to reject (i.e. refuse to run) programs
that have run-time detected violations of pragma Restrictions, when they
are detectable at compile time? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Whenever enforcement of a restriction imposed by pragma Restrictions
is not required by the standard prior to execution, but left to
implementation-defined behaviour of dynamic semantics, it is
reasonable to interpret pre-execution enforcement as a valid
implementation-defined behaviour, provided that every execution of the
partition will violate the restriction.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.12(9):   </FONT></B></P>
<UL><P>An implementation may place limitations on the values of the <FONT FACE="Arial, Helvetica">expression</FONT>
that are supported, and limitations on the supported combinations of
restrictions. The consequences of violating such limitations are
implementation defined.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>Whenever enforcement of a restriction is not required prior to
execution, an implementation may nevertheless enforce the restriction prior to
execution of a partition to which the restriction applies, provided
that every execution of the partition would violate the restriction.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>For the particularly critical rejection of programs that violate
restrictions imposed by pragma Restrictions, the standard provides for
implementation-defined behaviour in lieu of a compile- or link-time
check otherwise required by 13.12(8). It is reasonable to interpret
pre-execution enforcement of a configuration pragma as a valid
implementation-defined behaviour, even if such enforcement is not
required to occur prior to execution. This is particularly true for
D.7(15), as this clause recommends the raising of a Storage_Error
exception but does not specify the place where such an exception is to
be raised.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0044"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0044 -  Components of Stream_Element_Array should be aliased</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00181<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.13.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>13.13.1(4) does not define the components of
Streams.Stream_Element_Array to be aliased.  However, this makes various
uses of this type inconvenient.  What is the intent?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The components of Streams.Stream_Element_Array are aliased:
</P>
<PRE><TT><UL><B>type</B> Stream_Element_Array <B>is</B>
   <B>array</B>(Stream_Element_Offset <B>range</B> &lt;&gt;) <B>of</B> <B>aliased</B> Stream_Element;
                                            ^^^^^^^
</UL></TT></PRE>
<P>The following implementation permission is added:
</P>
<P><UL>If Stream_Element'Size is not a multiple of System.Storage_Unit,
then the components of Stream_Element_Array need not be aliased.
</UL></P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">In  13.13.1(4) replace:   </FONT></B></P>
<UL><UL><PRE><TT>
<B>type</B> Stream_Element_Array <B>is</B>
    <B>array</B>(Stream_Element_Offset <B>range</B> &lt;&gt;) <B>of</B> Stream_Element;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>
<B>type</B> Stream_Element_Array <B>is</B>
    <B>array</B>(Stream_Element_Offset <B>range</B> &lt;&gt;) <B>of aliased</B> Stream_Element;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.13.1(9):   </FONT></B></P>
<UL><P>The Write operation appends Item to the specified stream.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P><I><FONT SIZE=-2>Implementation Permissions</FONT></I>
</P></UL>
<UL><P>If Stream_Element'Size is not a multiple of System.Storage_Unit,
then the components of Stream_Element_Array need not be aliased.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>On machines where it is feasible, the components should be aliased.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>On machines where it is feasible, one should be allowed to form access
values pointing to any component within a Stream_Element_Array.
However, this package was intentionally designed to support machines
where the addressable unit is different from the unit of storage used by
the &quot;network&quot;.  Therefore, the requirement to be aliased is relaxed on
such machines.  Programmers wishing to write code that is portable to
such machines should not take advantage of the aliased components.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0045"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0045 -  Exception raised at end of stream</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00132<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.13.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Suppose one gets a stream from the Ada.Text_IO.Streams.Stream function.
(The same question applies to the Wide_Text_IO version, and also to
streams created by Ada.Streams.Stream_IO.)
</P>
<P>What happens if the stream's position corresponds to end-of-file, and
one tries to get an item using the default version of T'Read, for some
type T?  Is Data_Error or End_Error raised?  Can the result be abnormal?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If the default version of T'Read (for some type T) is used to read from
a stream, then if end of stream is encountered, End_Error is raised.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.13.2(35):   </FONT></B></P>
<UL><P>In the default implementation of Read and Input for a composite type,
for each scalar component that is a discriminant or whose
<FONT FACE="Arial, Helvetica">component_declaration</FONT> includes a <FONT FACE="Arial, Helvetica">default_expression</FONT>, a check is
made that the value
returned by Read for the component belongs to its subtype. Constraint_Error
is raised if this check fails. For other scalar components, no check is
made. For each component that is of an access type, if the implementation
can detect that the value returned by Read for the component is not a value
of its subtype, Constraint_Error is raised. If the value is not a value of
its subtype and this error is not detected, the component has an abnormal
value, and erroneous execution can result (see 13.9.1).
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>In the default implementation of Read and Input for a type, End_Error
is raised if the end of the stream is reached before the reading of a value of
the type is completed.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>13.13.1(8) admits to the notion of &quot;end of stream&quot; for stream types:
</P>
<P><UL>The Read operation transfers Item'Length stream elements from the
specified stream to fill the array Item. The index of the last
stream element transferred is returned in Last. Last is less than
Item'Last only if the end of the stream is reached.
</UL></P>
<P>The Read operation does not raise any exception at end of stream -- it
just indicates this fact in the value returned in Last. Of course, what
constitutes end of stream is defined by the particular stream type. The
stream returned by Text_Streams.Stream has a notion of end of stream
that corresponds to the end of the text file. A user-defined stream
might have a different notion of end of stream, or might not have any
such notion -- it is quite possible to implement a stream type that
represents an infinitely long sequence.
</P>
<P>So the question is, if a given stream type has a notion of end of
stream, then what happens when T'Read hits the end (which it can detect
by looking at the Last parameter returned by Streams.Read)?
</P>
<P>A.13(13,17) say:
</P>
<P><UL>The exception Data_Error can be propagated by the procedure Read (or by
the Read attribute) if the element read cannot be interpreted as a value of
the required subtype. ...
</UL></P>
<P><UL>If the element read by the procedure Read (or by the Read attribute)
cannot be interpreted as a value of the required subtype, but this is not
detected and Data_Error is not propagated, then the resulting value can be
abnormal, and subsequent references to the value can lead to erroneous
execution, as explained in 13.9.1.
</UL></P>
<P>Note that it is somewhat odd that the Read attribute can raise
IO_Exceptions.Data_Error, since streams have nothing directly to do with
I/O, and a given invocation of the Read attribute does not know whether
it is dealing with a file stream or not. Nonetheless, that's what it
says. Raising IO_Exceptions.End_Error is no more or less odd in this
regard.
</P>
<P>Possibilities are:
</P>
<P>Alternative 1: Either Data_Error is raised, or an abnormal value is
returned. This alternative is supported by the wording of A.13(13,17).
Reading zero bytes, or an insufficient number of bytes, clearly gives a
malformed piece of data. The programmer is forced to encode the number
of elements in the stream somehow, or otherwise encode the end of stream
explicitly, in order to avoid erroneous execution.
</P>
<P>Alternative 2: Data_Error is raised. There is really no implementation
reason for allowing abnormal values, since the condition is easy to
detect, and a very minor efficiency hit. However, this alternative
still forces the programmer to encode the end of stream by hand, since
Data_Error does not distinguish between malformed data and end of
stream.
</P>
<P>Alternative 3: End_Error is raised. This alternative <I>still</I> forces the
programmer to encode the end of stream by hand, because it does not
distinguish between encountering the end of the stream in between stream
elements, versus in the middle of an element -- the latter being a case
of malformed data.
</P>
<P>Alternative 4: End_Error is raised if the programmer calls the T'Read
and the stream is at end of stream. However, Data_Error is raised if
end of stream is encountered in the middle. This allows the programmer
to reliably read a sequence of items from a stream, and notice when the
last item has been read (by detecting End_Error), and distinguish this
situation from malformed data (Data_Error). Thus, the programmer does
not need to add extra data to the stream to explicitly encode end of
stream. However, this alternative is harder to implement, since Read
attributes are highly recursive. For example, suppose T is a record
type with two components. If 'Read raises End_Error on the second
component, T'Read must catch that exception, and turn it into Data_Error
-- the second component wasn't malformed, but the record as a whole <I>is</I>
malformed. On the other hand, an End_Error raised by reading the first
component would simply be propagated by T'Read. In addition, if the
user-defined overriding of the Read attribute would presumably want to
mimic this behavior. (Note: AI83-00307 requires a similar behavior for
Get procedures in Text_IO.)
</P>
<P>Alternatives 5,6,7,8: Same as alternatives 1,2,3,4, but define
Data_Error and/or End_Error exceptions in Streams, rather than using the
ones from IO_Exceptions. This might be more elegant, but serves no
practical purpose, and is too big a change to make at this point.
</P>
<P>We choose Alternative 3, because it seems the friendliest alternative
that has a reasonable implementation cost.
</P>
<P>The programmer can reliably detect end-of-file for file streams as
follows:
</P>
<PRE><TT><UL><B>if</B> <B>not</B> End_Of_File(An_Input_File) <B>then</B>
   T'Read(Stream(An_Input_File), Value);
   ...
<B>end</B> <B>if</B>;
</UL></TT></PRE>

<P><BR><BR></P>
<HR>

<A NAME="8652/0046"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0046 -  Freezing rules</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00106<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 13.14</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>1. Does an object_renaming_declaration cause freezing of the renamed
object?  (Yes.)
</P>
<P>For example, is the following legal?  (No.)
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    <B>type</B> T <B>is</B> <B>private</B>;
    <B>type</B> Acc <B>is</B> <B>access</B> T;
    X: Acc;
    Y: T <B>renames</B> X.all; -- Illegal!
<B>private</B>
    <B>type</B> T <B>is</B> ...;
<B>end</B> P;
</UL></TT></PRE>
<P>----------------
</P>
<P>2. Now, consider the following example:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    <B>type</B> T(D: Integer) <B>is</B> <B>private</B>;
    <B>type</B> A <B>is</B> <B>access</B> T;
    Obj: A;
    I: Integer := Obj.D; -- Does this freeze T? (Yes,
                         -- and it's therefore illegal.)
<B>private</B>
    <B>type</B> T(D: Integer) <B>is</B> ...;
<B>end</B> P;
</UL></TT></PRE>
<P>Does the declaration of I freeze the type T? (Yes.) If we replaced &quot;Obj.D&quot;
with &quot;Obj.all.D&quot;, then it would freeze T, and therefore be illegal.
</P>
<P>13.14(11) says:
</P>
<P><UL>At the place where a name
causes freezing, the entity denoted by the name is frozen, unless
the name is a prefix of an expanded name; at the place where an
object name causes freezing, the nominal subtype associated with
the name is frozen.
</UL></P>
<P>And AARM 13.14(11.a-11.b) say:
</P>
<P><UL>Ramification:  This only matters in the presence of deferred
constants or access types; an object_declaration other than a
deferred_constant_declaration causes freezing of the nominal
subtype, plus all component junk.
</UL></P>
<P><UL>Implicit_dereferences are covered by expression.
</UL></P>
<P>It seems that AARM 13.14(11.b) is wrong -- an implicit_dereference is <I>not</I> an
expression.
</P>
<P>----------------
</P>
<P>3. Does an implicit call to Initialize freeze the subprogram? (Yes.) The
freezing rules seem to apply to explicit constructs. For example:
</P>
<PRE><TT><UL><B>type</B> T <B>is</B> <B>new</B> Controlled <B>with</B> record...;
<B>procedure</B> Initialize(X: <B>in</B> <B>out</B> T);
X: T; -- Implicit call to Initialize.
<B>for</B> Initialize'Address <B>use</B> ...; -- Legal?  (No.)
</UL></TT></PRE>
<P>If this is legal, it will raise Program_Error, but AARM 13.14(1.o) argues
that that's no excuse.
</P>
<P>The same question applies to Adjust and Finalize, and also to implicit
calls to user-defined storage pool operations.
</P>
<P>----------------
</P>
<P>4. It seems unclear whether an implicit type conversion freezes. For
example:
</P>
<PRE><TT><UL><B>type</B> Color <B>is</B> (Red, Yellow);
<B>subtype</B> S <B>is</B> Color <B>range</B> Red..Red; -- The expression &quot;Red&quot; freezes type Color.
</UL></TT></PRE>
<P>But:
</P>
<PRE><TT><UL><B>type</B> T <B>is</B> <B>range</B> 1..100;
<B>subtype</B> S <B>is</B> T <B>range</B> 1..10; -- Freezes type T?  (Yes.)
</UL></TT></PRE>
<P>The expressions &quot;1&quot; and &quot;10&quot; are of type universal_integer, so T is not
frozen. But it seems like it should be -- the value is implicitly
converted to type T, and so it's very much like an expression of type T.
</P>
<P>13.14(12) seems to agree that the implicit conversion should freeze.
</P>
<P><UL>At the place where a range
causes freezing, the type of the range is frozen.
</UL></P>
<P>Here's a case not covered by 13.14(12):
</P>
<PRE><TT><UL><B>type</B> T <B>is</B> <B>range</B> 1..10;
<B>function</B> F(X: T) <B>return</B> boolean;
X: Boolean := F(10); -- Freezes type T?  (Yes.)
<B>for</B> T'Size <B>use</B> 4; -- Legal?  (No.)
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>1. An object name causes freezing where it occurs, unless the name is
part of a default_expression, a default_name, or a per-object expression
of a component's constraint, in which case, the freezing occurs later as
part of another construct.
</P>
<P>2. An implicit_dereference freezes entities according to the same rule
that applies to a name that is an explicit_dereference.
</P>
<P>3. An implicit call, such as an implicit call to Initialize, freezes the
called subprogram. This is true even if the implicit call is removed
via the implementation permissions in 7.6(18-21).
</P>
<P>4. If a name or expression is implicitly converted to a type or subtype,
then that type or subtype is frozen at the same place where the name or
expression causes freezing.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.14(4):   </FONT></B></P>
<UL><P>A construct that (explicitly or implicitly) references an entity can
cause the <I>freezing</I> of the entity, as defined by subsequent paragraphs. At
the place where a construct causes freezing, each <FONT FACE="Arial, Helvetica">name</FONT>, expression,
or <FONT FACE="Arial, Helvetica">range</FONT> within the construct causes freezing:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A construct that (explicitly or implicitly) references an entity can
cause the <I>freezing</I> of the entity, as defined by subsequent paragraphs. At
the place where a construct causes freezing, each <FONT FACE="Arial, Helvetica">name</FONT>, <FONT FACE="Arial, Helvetica">expression</FONT>,
<FONT FACE="Arial, Helvetica">implicit_dereference</FONT>, or <FONT FACE="Arial, Helvetica">range</FONT> within the construct causes freezing:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  13.14(8):   </FONT></B></P>
<UL><P>A static expression causes freezing where it occurs. A nonstatic
expression causes freezing where it occurs, unless the expression is part of
a <FONT FACE="Arial, Helvetica">default_expression</FONT>, a <FONT FACE="Arial, Helvetica">default_name</FONT>, or a per-object expression of a
component's <FONT FACE="Arial, Helvetica">constraint</FONT>, in which case, the freezing occurs later as part of
another construct.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A static expression causes freezing where it occurs. An object
name or nonstatic expression causes freezing where it occurs, unless
the name or expression is part of a <FONT FACE="Arial, Helvetica">default_expression</FONT>, a
<FONT FACE="Arial, Helvetica">default_name</FONT>, or a per-object expression of a component's <FONT FACE="Arial, Helvetica">constraint</FONT>,
in which case, the freezing occurs later as part of another construct.
</P></UL>
<UL><P>An implicit call freezes the same entities that would
be frozen by an explicit call. This is true even if the implicit
call is removed via implementation permissions.
</P></UL>
<UL><P>If an expression is implicitly converted to a type or subtype <I>T</I>,
then at the place where the expression causes freezing,
<I>T</I> is frozen.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  13.14(11):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
At the place where a <FONT FACE="Arial, Helvetica">name</FONT> causes freezing, the entity denoted by
the <FONT FACE="Arial, Helvetica">name</FONT> is frozen, unless the <FONT FACE="Arial, Helvetica">name</FONT> is a <FONT FACE="Arial, Helvetica">prefix</FONT> of an expanded
name; at the place where an object <FONT FACE="Arial, Helvetica">name</FONT> causes freezing, the
nominal subtype associated with the <FONT FACE="Arial, Helvetica">name</FONT> is frozen.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
At the place where an <FONT FACE="Arial, Helvetica">implicit_dereference</FONT> causes freezing,
the nominal subtype associated with the <FONT FACE="Arial, Helvetica">implicit_dereference</FONT> is frozen.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>1. 13.14(8) says that expressions cause freezing. It does not cover
names that denote objects, but it should -- the reasons for the
existence of 13.14(8) apply equally to object names.
</P>
<P>Given the conclusion herein reached, the above example (1) is illegal.
The occurrence of &quot;X.all&quot; freezes the type T, but the type is not
completely defined at that point, thus violating 13.14(17). Note that
the declaration of Y is an object_renaming_declaration, not an
object_declaration, so 13.14(6) does not apply.
</P>
<P>If the above example (1) were legal, it would necessarily raise
Constraint_Error due to dereferencing a null access value.
However, AARM 13.14(1.o-1.u) explains that we do not wish to rely on
run-time checks for this kind of example. Furthermore, it is possible
to construct examples that do not necessarily raise an exception.
</P>
<P>Object_renaming_declarations are not the only offender. Here's another
example:
</P>
<PRE><TT><UL><B>with</B> System.Storage_Pools; <B>use</B> System.Storage_Pools;
<B>package</B> Q <B>is</B>
    <B>type</B> My_Pool <B>is</B> <B>new</B> Root_Storage_Pool <B>with</B> <B>private</B>;
    <B>type</B> My_Pool_Ptr <B>is</B> <B>access</B> <B>all</B> My_Pool;
    Ptr: My_Pool_Ptr;
</UL></TT></PRE>
<PRE><TT><UL>    <B>type</B> Acc <B>is</B> <B>access</B> Integer;
    <B>for</B> Acc'Storage_Pool <B>use</B> Ptr.all; -- Illegal!
<B>private</B>
    <B>type</B> My_Pool <B>is</B> <B>new</B> Root_Storage_Pool <B>with</B> ...;
<B>end</B> Q;
</UL></TT></PRE>
<P>The above is illegal because the name &quot;Ptr.all&quot; freezes type My_Pool
before My_Pool is completely defined.
</P>
<P>The problem occurs in any case where an object name can occur, and is
analogous to the expression case in 13.14(8); hence the resolution
is worded by analogy with 13.14(8).
</P>
<P>----------------
</P>
<P>2. Clearly, the same rules should apply to explicit and
implicit dereferences -- in the example, &quot;Obj.all.D&quot; and &quot;Obj.D&quot; should
freeze the same entities. Therefore, a new bullet after 13.14(11) is added
to cover implicit_dereferences, so that the &quot;Obj&quot; in &quot;Obj.D&quot; freezes the same
entities that &quot;Obj.all&quot; would freeze. That is, an implicit_dereference
freezes the denoted object and its nominal subtype.
</P>
<P>Since an implicit_dereference is not an expression and is not a name
(although it may be part of a name), it is added to 13.14(4).
</P>
<P>----------------
</P>
<P>3 and 4. Clearly implicit calls and implicit conversions should freeze
in the same manner as their explicit counterparts. An implicit call
should freeze even if it is removed via the implementation permissions
in 7.6(18-21); otherwise, there would be a portability problem.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0047"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0047 -  Integer_Text_IO, etc. not listed in A(2)</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00081<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Integer_Text_IO and Float_Text_IO are not listed in A(2), but
Elementary_Functions (for example) is listed. Is this intended? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Integer_Text_IO and Float_Text_IO should be listed in A(2). Similarly,
Integer_Wide_Text_IO and Float_Wide_Text_IO should be listed in A(2).
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">In  A(2) replace:   </FONT></B></P>
<UL><P>Finalization -- 7.6<BR>
Interrupts -- C.3.2
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Finalization -- 7.6<BR>
Float_Text_IO -- A.10.9<BR>
Float_Wide_Text_IO -- A.11<BR>
Integer_Text_IO -- A.10.8<BR>
Integer_Wide_Text_IO -- A.11<BR>
Interrupts -- C.3.2
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This was an oversight.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0048"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0048 -  Bounds of string returned by Ada.Strings.Maps.To_Range</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00151<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.4.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A.4.2(63) says:
</P>
<P><UL>To_Range returns the Character_Sequence value R, with lower
bound 1 and upper bound Map'Length, such that if D = To_Domain(Map)
then D(I) maps to R(I) for each I in D'Range.
</UL></P>
<P>However, Map is not an array, so Map'Length makes no sense.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>To_Range returns the Character_Sequence value R, such that if D =
To_Domain (Map), then R has the same bounds as D, and D(I) maps to R(I)
for each I in D'Range.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.2(63):   </FONT></B></P>
<P><UL><UL>
To_Range returns the Character_Sequence value R, with lower
bound 1 and upper bound Map'Length, such that if D = To_Domain(Map)
then D(I) maps to R(I) for each I in D'Range.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
To_Range returns the Character_Sequence value R, such that if D =
To_Domain (Map), then R has the same bounds as D, and D(I) maps to R(I)
for each I in D'Range.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The simplest fix is to specify that the bounds are the same as those for
To_Domain.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0049"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0049 -  String packages</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00128<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.4.3;  A.4.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>1. The string packages (e.g., Ada.Strings.Fixed) have a procedure named
Find_Token whose profile is:
</P>
<PRE><TT><UL><B>procedure</B> Find_Token (Source : <B>in</B> String;
                      Set : <B>in</B> Maps.Character_Set;
                      Test : <B>in</B> Membership;
                      First : <B>out</B> Positive;
                      Last : <B>out</B> Natural);
</UL></TT></PRE>
<P>The semantics of this operation states that (A.4.3(68)) &quot;if no such
slice exists, then the value returned for Last is zero, and the value
returned for First is Source'First.&quot;
</P>
<P>What happens when Source'First is not in Positive (which can happen only
if Source is a null string)?  (It raises Constraint_Error.)
</P>
<P>2. The semantics of Bounded.Slice is stated as follows (A.4.4(101)):
&quot;Returns the slice at positions Low through High in the string
represented by Source; propagates Index_Error if Low &gt;
Length(Source)+1.&quot;
</P>
<P>What happens when Low &lt;= Length(Source)+1 and High &gt; Length(Source)?
Should it raise an exception?  If so which one?  Or should it return all
characters from Low to Length(Source)?  (It raises Index_Error.)
</P>
<P>3. The semantics of many subprograms of package Bounded is defined in
terms of the semantics of the corresponding subprograms of package Fixed
(A.4.4(102-105)).  The meaning is clear in most cases, except for Head
and Tail.
</P>
<P>A.4.4(105) says: &quot;Each of the ... selector subprograms (Trim, Head,
Tail) ... has an effect based on its corresponding subprogram in
Strings.Fixed ...&quot;
</P>
<P>The procedure Fixed.Head has the following profile:
</P>
<PRE><TT><UL><B>procedure</B> Head (Source : <B>in</B> <B>out</B> String;
                Count : <B>in</B> Natural;
                Justify : <B>in</B> Alignment := Left;
                Pad : <B>in</B> Character := Space);
</UL></TT></PRE>
<P>and the procedure Bounded.Head has a rather different profile:
</P>
<PRE><TT><UL><B>procedure</B> Head (Source : <B>in</B> <B>out</B> Bounded_String;
                Count : <B>in</B> Natural;
                Pad : <B>in</B> Character := Space;
                Drop : <B>in</B> Truncation := Error);
</UL></TT></PRE>
<P>Because the profiles are different, the &quot;effect based on the
corresponding subprogram&quot; is not very clear.  It is interesting to note
that the semantics of the operations of package Unbounded makes a
distinction between functions and procedures (A.4.5(86-87)), which
clarifies very much the meaning.  Is the intent similar for Bounded?
</P>
<P>The issue seems to be broader than Head and Tail: take for instance
procedure Bounded.Replace_Slice.  Is it based on the function
Fixed.Replace_Slice, or on the procedure Fixed.Replace_Slice?  The
effect is rather different, since the procedure doesn't change the
length of its argument, while the function may return a string of a
different length than its argument.
</P>
<P>4. A.4.3(2) says:
</P>
<P><UL>For each function that returns a String, the lower bound of the returned
value is 1.
</UL></P>
<P>However, A.4.3(73) says:
</P>
<PRE><TT><UL><B>function</B> Replace_Slice (Source   : <B>in</B> String;
                        Low      : <B>in</B> Positive;
                        High     : <B>in</B> Natural;
                        By       : <B>in</B> String)
       <B>return</B> String;
</UL></TT></PRE>
<P><UL>If Low &gt; Source'Last+1, or High &lt; Source'First-1, then Index_Error
is propagated.  Otherwise, if High &gt;= Low then the returned
string comprises Source(Source'First..Low-1) &amp; By &amp;
Source(High+1..Source'Last), and if High &lt; Low then the returned
string is Insert(Source, Before=&gt;Low, New_Item=&gt;By).
</UL></P>
<P>The lower bounds of the above concatenations give Source'First as the
lower bound, which might not be 1.
</P>
<P>Is the lower bound really 1?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>This resolution clarifies minor details of the semantics of some of the
string-manipulation subprograms:
</P>
<P>1. Fixed.Find_Token raises Constraint_Error if the value returned for
First is not in Positive.
</P>
<P>2. A call to Bounded.Slice with High &gt; Length(Source) raises
Index_Error.
</P>
<P>3. The functions in Bounded, such as Replace_Slice, are defined in terms
of the corresponding functions in Fixed, and the procedures in Bounded
are defined in terms of the functions in Bounded.
</P>
<P>4. A.4.3(2) holds throughout A.4.3.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.3(68):   </FONT></B></P>
<P><UL><UL>
Find_Token returns in First and Last the indices of the
beginning and end of the first slice of Source all of whose elements
satisfy the Test condition, and such that the elements (if any)
immediately before and after the slice do not satisfy the Test
condition. If no such slice exists, then the value returned for Last
is zero, and the value returned for First is Source'First.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
Find_Token returns in First and Last the indices of the
beginning and end of the first slice of Source all of whose elements
satisfy the Test condition, and such that the elements (if any)
immediately before and after the slice do not satisfy the Test
condition. If no such slice exists, then the value returned for Last
is zero, and the value returned for First is Source'First;
however, if Source'First is not in Positive then Constraint_Error is raised.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.3(74):   </FONT></B></P>
<P><UL><UL>
If Low &gt; Source'Last+1, or High &lt; Source'First-1, then Index_Error
is propagated. Otherwise, if High &gt;= Low then the returned
string comprises Source(Source'First..Low-1) &amp; By &amp;
Source(High+1..Source'Last), and if High &lt; Low then the returned
string is Insert(Source, Before=&gt;Low, New_Item=&gt;By).</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
If Low &gt; Source'Last+1, or High &lt; Source'First-1, then Index_Error
is propagated. Otherwise:</UL></UL></P>
<UL><UL><UL><LI TYPE=DISC>
If High &gt;= Low, then the returned
string comprises Source(Source'First..Low-1) &amp; By &amp;
Source(High+1..Source'Last), but with lower bound 1.</LI></UL></UL></UL>
<UL><UL><UL><LI TYPE=DISC>
If High &lt; Low, then the returned string is Insert(Source,
Before=&gt;Low, New_Item=&gt;By).</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.3(86):   </FONT></B></P>
<P><UL><UL>
If From &lt;= Through, the returned string is Replace_Slice(Source,
From, Through, &quot;&quot;), otherwise it is Source.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
If From &lt;= Through, the returned string is Replace_Slice(Source,
From, Through, &quot;&quot;), otherwise it is Source with lower bound 1.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.3(106):   </FONT></B></P>
<P><UL><UL>
These functions replicate a character or string a specified
number of times. The first function returns a string whose length is
Left and each of whose elements is Right. The second function
returns a string whose length is Left*Right'Length and whose value is
the null string if Left = 0 and is (Left-1)*Right &amp; Right otherwise.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
These functions replicate a character or string a specified
number of times. The first function returns a string whose length is
Left and each of whose elements is Right. The second function
returns a string whose length is Left*Right'Length and whose value is
the null string if Left = 0 and otherwise is (Left-1)*Right &amp; Right with
lower bound 1.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.4(101):   </FONT></B></P>
<P><UL><UL>
Returns the slice at positions Low through High in the string
represented by Source; propagates Index_Error if Low &gt; Length(Source)+1.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
Returns the slice at positions Low through High in the string
represented by Source; propagates Index_Error if Low &gt; Length(Source)+1 or
High &gt; Length(Source).</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.4.4(105):   </FONT></B></P>
<UL><P>Each of the transformation subprograms (Replace_Slice, Insert,
Overwrite, Delete), selector subprograms (Trim, Head, Tail), and constructor
functions (&quot;*&quot;) has an effect based on its corresponding subprogram in
Strings.Fixed, and Replicate is based on Fixed.&quot;*&quot;. For each of these
subprograms, the corresponding fixed-length string subprogram is applied to
the string represented by the Bounded_String parameter. To_Bounded_String is
applied the result string, with Drop (or Error in the case of
Generic_Bounded_Length.&quot;*&quot;) determining the effect when the string length
exceeds Max_Length.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Each of the transformation subprograms (Replace_Slice, Insert,
Overwrite, Delete), selector subprograms (Trim, Head, Tail), and constructor
functions (&quot;*&quot;) has an effect based on its corresponding subprogram in
Strings.Fixed, and Replicate is based on Fixed.&quot;*&quot;. In the case of a function,
the corresponding fixed-length string function is applied to
the string represented by the Bounded_String parameter. To_Bounded_String is
applied to the result string, with Drop (or Error in the case of
Generic_Bounded_Length.&quot;*&quot;) determining the effect when the string length
exceeds Max_Length. In the case of a procedure, the corresponding function
in Strings.Bounded.Generic_Bounded_Length is applied, with the result assigned
into the Source parameter.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>1. Fixed.Find_Token raises Constraint_Error if the value returned for
First is not in Positive. Bounded.Find_Token and Unbounded.Find_Token's
string argument always has a lower bound of 1 (by definition), so the
question does not apply to them.
</P>
<P>2. A call to Bounded.Slice with High &gt; Length(Source) raises
Index_Error.  This is analogous to the normal string slicing operation.
</P>
<P>3. The <I>function</I> Bounded.Head is defined in terms of the function
Fixed.Head; a call of the function Bounded.Head is equivalent to:
</P>
<P><UL>To_Bounded_String(Fixed.Head(To_String(Source), Count, Pad), Drop =&gt; Drop)
</UL></P>
<P>The <I>procedure</I> Bounded.Head is defined in terms of the <I>function</I>
Bounded.Head; a call to the procedure Bounded.Head is equivalent to:
</P>
<P><UL>Source := Head(Source, Count, Pad, Drop);
</UL></P>
<P>Corresponding rules apply to Tail.  In general, the functions in
Bounded, such as Replace_Slice, are defined in terms of the
corresponding functions in Fixed, and the procedures in Bounded are
defined in terms of the functions in Bounded.
</P>
<P>4. Clearly, the intent is that the lower bound should always be 1, as
stated in A.4.3(2). A &quot;friendly&quot; reading is that A.4.3(74) is
just telling us the characters of the string (it says &quot;comprises&quot;, and
not &quot;is equivalent to&quot;), and is not intended to define the bounds.
</P>
<P>A.4.3(2) is therefore interpreted to hold throughout A.4.3.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0050"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0050 -  Float_Random.Value, Discrete_Random.Value</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00089<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.5.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A.5.2(40) says:
</P>
<P><UL>Invoking Value with a string that is not the image of any generator
state raises Constraint_Error.
</UL></P>
<P>Is it legal to allow some extra flexibility? (Yes.) For example, suppose the
Image function returns a representation of the state as a string of
hexadecimal digits, with 'A'..'F' in upper case. A string with 'a'..'f'
in lower case, but which is otherwise equivalent to a valid image, is
not strictly speaking &quot;the image of any generator state&quot;. May the Value
function nevertheless return a valid state for such a string, or must it
raise Constraint_Error?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>It is a bounded error to invoke Value with a string that is not the
image of any generator.  If the error is detected, Constraint_Error or
Program_Error is raised.  Otherwise, a call to Reset with the resulting
State will produce a generator such that calls to Random with this
generator will produce a sequence of values of the appropriate subtype,
but which might not be random in character.  That is, the sequence of
values might not fulfill the requirements of A.5.2(41-43).
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.5.2(40):   </FONT></B></P>
<UL><P>Invoking Value with a string that is not the image of any generator
state raises Constraint_Error.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P><FONT SIZE=-2><I>Bounded (Run-Time) Errors</I></FONT><BR>
It is a bounded error to invoke Value with a string that is not the
image of any generator state. If the error is detected, Constraint_Error or
Program_Error is raised. Otherwise, a call to Reset with the resulting
state will produce a generator such that calls to Random with this
generator will produce a sequence of values of the appropriate subtype,
but which might not be random in character. That is, the sequence of
values might not fulfill the implementation requirements of this subclause.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>A.5.2(40) seems to imply that the implementation must detect strings
that could not have been produced by Image. However, for some kinds of
random number generators, such detection is prohibitively expensive.
Therefore, we choose to make this situation a bounded error. If the
given string is syntactically malformed, the implementation will
probably raise an exception. However, some strings might &quot;look right&quot;,
but produce a generator state that could never come from a valid seed,
and results in non-random numbers.
</P>
<P>There is no need to make the situation erroneous -- the implementation
shouldn't write to random memory locations, or take wild jumps. The
worst that can happen is that a non-random sequence of numbers (for
example, a sequence of zeros) will be produced.
</P>
<P>To be portable, the programmer should ensure that every string passed to
Value came originally from a call to Image.
</P>
<P>Note that A.5.2(45) says, &quot;The implementation ... shall document the
nature of the strings that Value will accept without raising
Constraint_Error.&quot;
</P>
<P>The reason for adding Program_Error to the list of possibilities is
simply that 1.1.5(8) says that every bounded error can raise
Program_Error.
</P>
<P>Note that this ruling does not allow calls to Random to raise
Constraint_Error or Program_Error.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0051"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0051 -  Text_IO.Flush should use mode 'in'</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00057<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.10.1;  A.10.3;  A.12.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A.10.1(21) shows the parameter of Text_IO.Flush as mode 'in out'.
This makes it impossible to flush Standard_Output.  Is this the
intent?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The mode of the parameter of Text_IO.Flush is 'in' (not 'in out').
The same is true of Streams.Stream_IO.Flush.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.10.1(21):   </FONT></B></P>
<UL><P><I>-- Buffer control</I>
</P></UL>
<UL><UL><PRE><TT><B>procedure</B> Flush (File : <B>in out</B> File_Type);
<B>procedure</B> Flush;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P><I>-- Buffer control</I>
</P></UL>
<UL><UL><PRE><TT><B>procedure</B> Flush (File : <B>in</B> File_Type);
<B>procedure</B> Flush;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.10.3(20):   </FONT></B></P>
<UL><UL><PRE><TT><B>procedure</B> Flush (File : <B>in out</B> File_Type);
<B>procedure</B> Flush;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>procedure</B> Flush (File : <B>in</B> File_Type);
<B>procedure</B> Flush;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.12.1(25):   </FONT></B></P>
<UL><UL><PRE><TT><B>procedure</B> Flush (File : <B>in out</B> File_Type);</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>procedure</B> Flush (File : <B>in</B> File_Type);</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The parameter mode of Text_IO.Flush and Stream_IO.Flush is 'in'
(not 'in out', as shown in the International Standard).
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It is important to be able to call Flush on the Current_Output,
Standard_Output, Current_Error, and Standard_Error files.
However, these files are only accessible via function results
or dereferencing an access-to-constant value; thus they cannot
be flushed if the mode is 'in out'.
</P>
<P>Note that Current_Output is flushed by the parameterless Flush procedure
(see A.10.3(21)); thus it had better make sense to flush Current_Output.
</P>
<P>Therefore, we make the mode of the parameter of Flush be 'in'.
This is consistent with procedures like Put, which also modify
the file; a level of indirection is presumed in the implementation.
</P>
<P>For consistency, the same applies to Stream_IO.Flush (see A.12.1(25)).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0052"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0052 -  Error in Standard_Error definition</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00194<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.10.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>In the definition of the Text_IO.Standard_Error function with result type
File_Access, the standard states that the returned access value designates
&quot;the standard output file.&quot;  This is just a typographical error,
right? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A.10.3(12) should refer to the standard error file, not to the standard
output file.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.10.3(12):   </FONT></B></P>
<P><UL><UL>
Returns the standard error file (see A.10), or an access value
designating the standard output file, respectively.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
Returns the standard error file (see A.10), or an access value
designating the standard error file, respectively.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent here is obvious; this is just an editing error.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0053"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0053 -  Erroneous execution for closing default files</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00063<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.10.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A.10.3(23) states:
</P>
<P><UL>If the Close operation is applied to a file object that is also serving
as the default input, default output, or default error file, then subsequent
operations on such a default file are erroneous.
</UL></P>
<P>This seems to imply that once the Close operation is done to, say, the
default output file, any further reference to the default output file is
erroneous, even if the default output file has been set to a different
(open) file.  That is, closing a file that happens to be the default
output file poisons any reference to a <I>different</I> default output file.
Is this the intent?  (No.)
</P>
<P>Consider:
</P>
<PRE><TT><UL>Set_Output(File_1);
Close(File_1);
Set_Output(File_2);
Put(X); -- Erroneous?  (No.)
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An operation on a default file is erroneous if the corresponding file
object is closed at the time the operation is invoked.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.10.3(22):   </FONT></B></P>
<UL><P>The execution of a program is erroneous if it attempts to use a current
default input, default output, or default error file that no longer exists.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The execution of a program is erroneous if it invokes an operation on a
current default input, default output, or default error file, and if the
corresponding file object is closed or no longer exists.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Delete  A.10.3(23):  </FONT></B></P>
<UL><P>If the Close operation is applied to a file object that is also serving
as the default input, default output, or default error file, then subsequent
operations on such a default file are erroneous.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The above interpretation makes the most sense -- it doesn't make sense
for a close to forever poison the default file.  That is, if you close
the default file, and then reference that default file, it should be
erroneous, but if you close the default file, then reset the default
file to refer to some other open file, then it should not be erroneous
to then reference the default file.
</P>
<P>In the above example, if there were no &quot;Set_Output(File_2);&quot;, then
execution would be erroneous.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0054"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0054 -  Enumeration_IO does not allow instantiation for a float type</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00007<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.10.10</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A.10.10(17) says: &quot;Enumeration_IO would allow instantiation for an float
type&quot;.  This is obviously a typographical error; &quot;integer&quot; is meant.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Enumeration_IO cannot be instantiated for a floating point type.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.10.10(17):   </FONT></B></P>
<UL><P>Although the specification of the generic package Enumeration_IO would
allow instantiation for an float type, this is not the intended purpose of
this generic package, and the effect of such instantiations is not defined by
the language.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Although the specification of the generic package Enumeration_IO would
allow instantiation for an integer type, this is not the intended purpose
of this generic package, and the effect of such instantiations is not
defined by the language.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Enumeration_IO cannot be instantiated for a floating point type.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0055"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0055 -  Stream_IO.Read and Stream_IO.Write advance the current index</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00026<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.12.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Which operations set and modify the current file index of a stream file?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Opening a file of type Streams.Stream_IO.File_Type in mode Append_File,
or resetting such a file to mode Append_File, sets the current file index
to Size(File)+1. Beyond this, the current file index maintained by
Stream_IO is set in the same manner as the current file index maintained
by instances of Direct_IO.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert before  A.12.1(2):   </FONT></B></P>
<UL><P>The library package Streams.Stream_IO has the following declaration:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>The elements of a stream file are stream elements. If positioning is supported
for the specified external file, a current index and current size are maintained
for the file as described in A.8. If positioning is not supported, a current
index is not maintained, and the current size is implementation defined.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  A.12.1(28):   </FONT></B></P>
<UL><P>The subprograms Create, Open, Close, Delete, Reset, Mode, Name, Form, Is_Open,
and End_of_File have the same effect as the corresponding subprograms in
Sequential_IO (see A.8.2).
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><P>The Set_Mode procedure changes the mode of the file. If the new mode is
Append_File, the file is positioned to its end; otherwise, the position in the
file is unchanged.
</P></UL>
<UL><P>The Flush procedure synchronizes the external file with the internal file (by
flushing any internal buffers) without closing the file or changing the
position. Mode_Error is propagated if the mode of the file is In_File.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  A.12.1(30):   </FONT></B></P>
<UL><P>The procedures Read and Write are equivalent to the corresponding
operations in the package Streams. Read propagates Mode_Error if the mode of
File is not In_File. Write propagates Mode_Error if the mode of File is not
Out_File or Append_File. The Read procedure with a Positive_Count parameter
starts reading at the specified index. The Write procedure with a
Positive_Count parameter starts writing at the specified index.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>The Size function returns the current size of the file.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.12.1(31):   </FONT></B></P>
<UL><P>The Index function returns the current file index, as a count (in stream
elements) from the beginning of the file. The position of the first element
in the file is 1.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The Index function returns the current index.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  A.12.1(32):   </FONT></B></P>
<UL><P>The Set_Index procedure sets the current index to the specified value.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><P>If positioning is supported for the external file, the current index is
maintained as follows:
</P></UL>
<UL><UL><LI TYPE=DISC>
For Open and Create, if the Mode parameter is Append_File, the current
index is set to the current size of the file plus one; otherwise, the current
index is set to one.</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
For Reset, if the Mode parameter is Append_File, or no Mode parameter
is given and the current mode is Append_File, the current index is set to the
current size of the file plus one; otherwise, the current index is set to one.</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
For Set_Mode, if the new mode is Append_File, the current index is set
to current size plus one; otherwise, the current index is unchanged.</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
For Read and Write without a Positive_Count parameter, the current
index is incremented by the number of stream elements read or written.</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
For Read and Write with a Positive_Count parameter, the value of the
current index is set to the value of the Positive_Count parameter plus the
number of stream elements read or written.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Delete  A.12.1(34):  </FONT></B></P>
<UL><P>The Size function returns the current size of the file, in stream elements.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Delete  A.12.1(35):  </FONT></B></P>
<UL><P>The Set_Mode procedure changes the mode of the file. If the new mode is
Append_File, the file is positioned to its end; otherwise, the position in
the file is unchanged.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Delete  A.12.1(36):  </FONT></B></P>
<UL><P>The Flush procedure synchronizes the external file with the internal file (by
flushing any internal buffers) without closing the file or changing the
position. Mode_Error is propagated if the mode of the file is In_File.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The following operations set the value of the current index if
positioning is supported for the specified file:
</P>
<P><UL>- Open(File,Mode,Name,Form) and Create(File,Mode,Name,Form) set the
current index to Size(File)+1 if Mode(File) = Append_File, and to 1
otherwise.
</UL></P>
<P><UL>- Read increments the current index by the number of stream elements
read.
</UL></P>
<P><UL>- Write increments the current index by the number of stream elements
written.
</UL></P>
<P><UL>- Set_Index(File,To) sets the current index to the value of To (which
may be greater than Size(File)).
</UL></P>
<P><UL>- Set_Mode(File,Mode) sets the current index to Size(File)+1 if Mode =
Append_File, and leaves it unchanged otherwise.
</UL></P>
<P><UL>- Reset(File,Mode) sets the current index to Size(File)+1 if Mode =
Append_File, and to 1 otherwise; Reset(File) sets the current index
to Size(File)+1 if Mode(File) = Append_File, and to 1 otherwise.
</UL></P>
<P>Set_Index and the versions of Read and Write with Positive_Count
parameters raise Use_Error if positioning is not supported for the
specified file.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>A.12.1 describes the current index, or position, of a stream file, but
does not indicate that its value is set by any operation other than
Set_Index and Set_Mode. Stream files also fail to describe their conceptual
model.
</P>
<P>The intent was that stream files that support positioning are similar to
direct files, and that other stream files are similar to sequential
files. Both of these file types are described in A.8. Note, however, that
A.8 specifically says it does not apply to stream files.
</P>
<P>Since stream files with positioning are intended to be similar to direct files,
the current index of a stream file should be handled similarly (except that
the index counts stream elements rather than file elements, and except that a
stream file can be opened in or reset to mode Append_File). The
recommendation is based on the behavior described in A.8(4), A.8.2, and
A.8.5 for direct files.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0056"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0056 -  Ada.Streams.Stream_IO.Stream can raise Status_Error</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00001<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.12.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>If the function Ada.Streams.Stream_IO.Stream is called with a closed
file, does the call raise Status_Error? (Yes.)
</P>
<P>If the function call does not raise Status_Error, does an attempt to
read from or write to the stream referenced by the resulting access
value raise Status_Error if the file has been closed? (It is erroneous.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Ada.Streams.Stream_IO.Stream raises Status_Error if its parameter is not
an open file. If the file passed to the Stream function is closed or
ceases to exist after the call on the Stream function and the
Root_Stream_Type'Class object designated by the function result is
subsequently passed as the first parameter to Ada.Streams.Read or
Ada.Streams.Write, execution is erroneous.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  A.12.1(29):   </FONT></B></P>
<UL><P>The Stream function returns a Stream_Access result from a File_Type
object, thus allowing the stream-oriented attributes Read, Write, Input, and
Output to be used on the same file for multiple types.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The Stream function returns a Stream_Access result from a File_Type
object, thus allowing the stream-oriented attributes Read, Write, Input, and
Output to be used on the same file for multiple types. Stream propagates
Status_Error if File is not open.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  A.12.1(36):   </FONT></B></P>
<UL><P>The Flush procedure synchronizes the external file with the internal
file (by flushing any internal buffers) without closing the file or changing
the position. Mode_Error is propagated if the mode of the file is In_File.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P><FONT SIZE=-2><I>Erroneous Execution</I></FONT><BR>
If the File_Type object passed to the Stream function
is later closed or finalized, and the stream-oriented attributes are
subsequently called (explicitly or implicitly) on the Stream_Access value
returned by Stream, execution is erroneous. This rule applies even if the
File_Type object was opened again after it had been closed.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The result of Ada.Streams.Stream_IO.Stream is associated with a specific
opening of the file passed as a parameter.
</P>
<P>A call on Stream raises Status_Error if its parameter is not an open file.
</P>
<P>If the file passed to Stream is closed after the call on Stream and the
Root_Stream_Type'Class object designated by the function result is
subsequently passed as the first parameter to Ada.Streams.Read or
Ada.Streams.Write, execution is erroneous, even if the file was opened
again after it was closed. (Such calls on Read or Write may arise
indirectly from calls on the subprograms denoted by the stream-oriented
attributes.)  Similarly, if the file passed to Stream ceases to exist
after the call on Stream (e.g., upon exit from the scope in which the
File_Type object was declared) and the object designated by the function
result is subsequently passed to Read or Write, execution is erroneous.
</P>
<P>It follows from A.12.2(5) that the same rules apply to
Ada.Text_IO.Text_Streams.Stream. It follows from A.12.3(5) that the
same rules apply to Ada.Wide_Text_IO.Text_Streams.Stream .
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Open, Create, and Is_Open are the only subprograms in predefined program
units that can be invoked with a closed file without raising
Status_Error.
</P>
<P>The rules stipulating when use of the result of the Stream function is
erroneous are analogous to the rules in A.10.3(22) and A.10.3(23) for the
result of the Current_Input, Current_Output, and Current_Error functions.
These rules make it possible to represent a File_Type value or a file
stream-value as an access value, with a null value corresponding to a closed
file. (By a file-stream value, we mean a value belonging to some
descendant of Root_Stream_Type and representing a stream associated with
a file.)
</P>
<P>The risk of erroneous execution can be minimized by using the Stream
function only as an actual parameter to Ada.Streams.Read,
Ada.Streams.Write, or a stream-oriented attribute.
</P>
<P>An alternative approach would be to allow the result of the Stream function to
correspond to a closed file, but to raise Status_Error upon an attempt
to use a file-stream value associated with a closed or no longer
existent file. Then a file-stream value would have to reflect the fact
that its corresponding internal file had been closed or had ceased to
exist. This would rule out an implementation in which closing a file
simply sets a File_Type value to a null pointer. Finalization of both
File_Type objects and file-stream objects would be complicated. (One
possible implementation would be for both File_Type objects and
file-stream objects to be controlled objects pointing to an object that
includes both a reference count and an is-opened flag. Such an object
would be allocated upon creation of a File_Type object, but would
continue to exist beyond the lifetime of the File_Type object if there
were still unfinalized file-stream objects pointing to it.)
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0057"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0057 -  External files of Standard_Input and Standard_Output</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00050<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 A.14</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A.14(2-3) say:
</P>
<P><UL>Operations on one text file object do not affect the column,
line, and page numbers of any other file object.
</UL></P>
<P><UL>Standard_Input and Standard_Output are associated with distinct
external files, so operations on one of these files cannot affect
operations on the other file. In particular, reading from
Standard_Input does not affect the current page, line, and column
numbers for Standard_Output, nor does writing to Standard_Output
affect the current page, line, and column numbers for
Standard_Input.
</UL></P>
<P>What is the intended meaning of the statement, &quot;Standard_Input and
Standard_Output are associated with distinct external files&quot;, given that
the operating system may well consider standard input and standard
output to be associated with the same device (say, a terminal)?
</P>
<P>The NOTE in A.10.3(25) contradicts A.14(3):
</P>
<P><UL>24  The standard input, standard output, and standard error files are
different file objects, but not necessarily different external files.
</UL></P>
<P>A.10(5-6) also discuss these files:
</P>
<P><UL>At the beginning of program execution the default input and output files
are the so-called standard input file and standard output file. These files
are open, have respectively the current modes In_File and Out_File, and are
associated with two implementation-defined external files. Procedures are
provided to change the current default input file and the current default
output file.
</UL></P>
<P><UL>At the beginning of program execution a default file for
program-dependent error-related text output is the so-called standard error
file. This file is open, has the current mode Out_File, and is associated
with an implementation-defined external file. A procedure is provided to
change the current default error file.
</UL></P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Standard_Input, Standard_Output, and Standard_Error are associated with
three distinct (internal) file objects. Their association with external
files is not specified by the language; in particular, these three
external files need not be distinct.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Delete  A.14(3):  </FONT></B></P>
<UL><UL><LI TYPE=DISC>
Standard_Input and Standard_Output are associated with distinct
external files, so operations on one of these files cannot affect
operations on the other file. In particular, reading from
Standard_Input does not affect the current page, line, and column
numbers for Standard_Output, nor does writing to Standard_Output
affect the current page, line, and column numbers for Standard_Input.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The NOTE in A.10.3(25) is correct. A.10(5-6) do not specifically say
whether the external files are distinct. In any case, external files
are &quot;external&quot; from the point of view of Ada semantics, so it's hard to
see how one could write a test case that distinguishes whether the
referenced statement is obeyed by an alleged implementation.
</P>
<P>On most operating systems, it is possible for Standard_Input and
Standard_Output to be associated with the same external file. This
happens by default, when they are both associated with the same terminal
device. It can also happen when the user redirects I/O to the same
file.
</P>
<P>It is not clear that A.14(3) is trying to say anything in addition to
what A.14(2) already says for all text files. Therefore, A.14(3) should
simply be removed.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0058"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0058 -  What are the rules for named notation in pragmas?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00036<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The syntax given for pragma Import is
</P>
<PRE><TT><UL><B>pragma</B> Import (
   [Convention =&gt; ] convention_identifier        -- (1)
   , [Entity =&gt;] local_name                      -- (2)
   [ , [External_Name =&gt; ] string_expression ]   -- (3)
   [ , [Link_Name =&gt; ] string_expression ] ) ;   -- (4)
</UL></TT></PRE>
<P>(and similarly for pragma Export).
</P>
<P>Does this imply that named notation cannot be used to reorder the
arguments?  For example, is the following pragma legal?  (No.)
</P>
<PRE><TT><UL><B>pragma</B> Import(C, Raise_Signal,
   Link_Name =&gt; &quot;raise&quot;, External_Name =&gt; &quot;._raise&quot;); -- Illegal!
</UL></TT></PRE>
<P>Secondly, is there a rule from which I can deduce that
</P>
<PRE><TT><UL><B>pragma</B> Import (C, Raise_Signal, &quot;raise&quot;);
</UL></TT></PRE>
<P>means
</P>
<PRE><TT><UL><B>pragma</B> Import (C, Raise_Signal, External_Name =&gt; &quot;raise&quot;);
</UL></TT></PRE>
<P>(by eliding the text in the outer brackets on line (4) and the text in
the inner brackets on line (3)) rather than
</P>
<PRE><TT><UL><B>pragma</B> Import (C, Raise_Signal, Link_Name =&gt; &quot;raise&quot;);
</UL></TT></PRE>
<P>(by eliding the text in the outer brackets on line (3) and the text in
the inner brackets on line(4))?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A pragma must obey the syntax rules for that particular pragma.
In particular, arguments written in named notation must not be given
in a different order than is required by the syntax rules.
</P>
<P>For pragma arguments written in positional notation, the first argument
corresponds to the first argument shown in the syntax rule for the
pragma, the second argument corresponds to the second, and so on.
This is true even in the presence of optional arguments.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  B.1(9):   </FONT></B></P>
<P><UL><UL>
A <FONT FACE="Arial, Helvetica">pragma</FONT> Linker_Options is allowed only at the place of a
<FONT FACE="Arial, Helvetica">declarative_item</FONT>.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<P><UL><UL>
For <FONT FACE="Arial, Helvetica">pragma</FONT>s Import and Export, the argument for Link_Name shall not
be given without the <FONT FACE="Arial, Helvetica">pragma_argument_identifier</FONT> unless the argument
for External_Name is given.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>As mentioned in AARM 2.8(11.i), it is not the intent to allow reordering,
even when named notation is used.
</P>
<P>For positional notation, the intent is that pragma arguments follow the
same rules as subprograms -- if positional notation is used, the
arguments are associated in order.  Thus,
</P>
<PRE><TT><UL><B>pragma</B> Import (C, Raise_Signal, &quot;raise&quot;);
</UL></TT></PRE>
<P>means:
</P>
<PRE><TT><UL><B>pragma</B> Import (C, Raise_Signal, External_Name =&gt; &quot;raise&quot;);
</UL></TT></PRE>
<P>since External_Name is the third argument of pragma Import.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0059"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0059 -  Interface to C -- passing records as parameters of mode 'in'</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00131<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The implementation advice B.3(69) says:
</P>
<P><UL>An Ada parameter of a record type T, of any mode, is passed as a
t* argument to a C function, where t is the C struct
corresponding to the Ada type T.
</UL></P>
<P>The problem with this is that if one has a C function that is passed a
struct, then how can one pass an Ada record to that?  One might think that if
the Ada record is passed as an 'in' parameter, it will work.  However, the
above implementation advice implies that such an 'in' parameter will
correspond to a t* on the C side, rather than a t.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The implementation advice in B.3(69) is correct as written.
</P>
<P>An implementation which supports interfacing to C shall support pragma
Convention with a C_Pass_By_Copy identifier. An 'in' parameter of a
C_Pass_By_Copy-compatible type T should be passed as a t argument to a C
function, where t is the C struct corresponding to type T.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3(1):   </FONT></B></P>
<UL><P>The facilities relevant to interfacing with the C language are the
package Interfaces.C and its children; and support for the Import, Export,
and Convention pragmas with <I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> C.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The facilities relevant to interfacing with the C language are the
package Interfaces.C and its children; support for the Import, Export,
and Convention pragmas with <I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> C; and support
for the Convention pragma with <I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> C_Pass_By_Copy.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  B.3(60):   </FONT></B></P>
<P><UL><UL>
The To_C and To_Ada subprograms that convert between Wide_String
and wchar_array have analogous effects to the To_C and To_Ada
subprograms that convert between String and char_array, except that
wide_nul is used instead of nul.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><P>A Convention pragma with <I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> C_Pass_By_Copy shall
only be applied to a type.
</P></UL>
<UL><P>The eligibility rules in B.1 do not apply to convention C_Pass_By_Copy.
Instead, a type T is eligible for convention C_Pass_By_Copy if T is a record
type that has no discriminants and that only has components with statically
constrained subtypes, and each component is C-compatible.
</P></UL>
<UL><P>If a type is C_Pass_By_Copy-compatible then it is also C-compatible.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3(61):   </FONT></B></P>
<UL><P>An implementation shall support pragma Convention with a C
<I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> for a C-eligible type (see B.1)
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An implementation shall support pragma Convention with a C
<I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> for a C-eligible type (see B.1).
An implementation shall support pragma Convention
with a C_Pass_By_Copy <I>convention_</I><FONT FACE="Arial, Helvetica">identifier</FONT> for a
C_Pass_By_Copy-eligible type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  B.3(68):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
An Ada <B>access</B> T parameter, or an Ada <B>out</B> or <B>in out</B> parameter of
an elementary type T, is passed as a t* argument to a C function,
where t is the C type corresponding to the Ada type T. In the
case of an elementary <B>out</B> or <B>in out</B> parameter, a pointer to a
temporary copy is used to preserve by-copy semantics.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
An Ada parameter of a C_Pass_By_Copy-compatible (record) type T,
of mode <B>in</B>, is passed as a t argument to a C function, where t is the
C struct corresponding to the Ada type T.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3(69):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
An Ada parameter of a record type T, of any mode, is passed as a
t* argument to a C function, where t is the C struct
corresponding to the Ada type T.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
An Ada parameter of a record type T, of any mode, other than an <B>in</B>
parameter of a C_Pass_By_Copy-compatible type, is passed as a
t* argument to a C function, where t is the C struct corresponding to the
Ada type T.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The implementation advice in B.3(69) is left unchanged (that is, C-compatible
records are passed by reference).
</P>
<P>The convention C_Pass_By_Copy is added to the facilities available for
interfacing with C.  This convention can only be used in pragma Convention
(not in pragmas Import or Export) and only when this pragma is applied to a
type.
</P>
<P>There is no language interface package corresponding to C_Pass_By_Copy.  In
other words, B.1(13) never applies to convention C_Pass_By_Copy, and there is
no package named Interfaces.C_Pass_By_Copy.
</P>
<P>A type T is eligible for convention C_Pass_By_Copy if T is a record type that
has no discriminants and that only has components with statically constrained
subtypes, and each component is C-compatible.  (The eligibility rules
in B.1(13-18) do not apply to convention C_Pass_By_Copy.)
</P>
<P>If a type is C_Pass_By_Copy-compatible then it is also C-compatible.
</P>
<P>An implementation supporting interfacing to C shall support pragma Convention
with a C_Pass_By_Copy convention_identifier for a C_Pass_By_Copy-eligible
type.
</P>
<P>The following sentence is added to the implementation advice in B.3(64-71):
</P>
<P>An Ada parameter of a C_Pass_By_Copy-compatible (record) type T, of mode in,
should be passed as a t argument to a C function, where t is the C struct
corresponding to the Ada type T.
</P>
<P>Note that the rules B.1(19) and B.1(20) apply to convention C_Pass_By_Copy.
In particular, an implementation may permit other types as
C_Pass_By_Copy-compatible types (e.g., discriminated records).
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It was a mistake to require pass-by-reference for records passed to C
functions.  However, at this point, it would be disruptive to change the
rule, and there is an alternative (see below).
</P>
<P>The most important use of this interface is to take an existing C interface,
and use it from Ada code (as opposed to taking an existing Ada interface, and
mapping it to some corresponding C code).
</P>
<P>Structs are passed by copy in C.  This can be implemented by passing a copy
of the struct (on the stack, in a register, or whatever), or by making a copy
at the call site, and passing the address of that copy.  Either way, whatever
the C compiler does, the goal should be for the Ada compiler to mimic the C
compiler's method of passing structs (not pointers to structs).
</P>
<P>Nonetheless, we choose to keep the implementation advice as is.  Instead, we
solve the problem by defining a new convention, C_Pass_By_Copy:
</P>
<PRE><TT><UL><B>pragma</B> Convention (C_Pass_By_Copy, T);
</UL></TT></PRE>
<P>The effect is that any 'in' parameter of the type T is passed by copy to a
subprogram of convention C, i.e., in a manner consistent with what C expects
if the corresponding formal in the C prototype is a struct (rather than a
pointer to a struct).
</P>
<P>In order to make sure that this solution is portable, an implementation that
supports interfacing to C is required to support convention C_Pass_By_Copy.
</P>
<P>Note that there is no issue for modes 'in out' and 'out'; C doesn't have
these modes, and the closest correspondence to C is a pointer-to-struct
argument.
</P>
<P>Although this is not explicitly stated in the International Standard, it is
clear that an Ada function with result type T corresponds to a C function
with return type t, where t is the C type corresponding to the Ada type T.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0060"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0060 -  In Interfaces.C, nul and wide_nul represent zero</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00037<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The following declarations appear in Interfaces.C (B.3):
</P>
<PRE><TT><UL>(19)   <B>type</B> char <B>is</B> <I>&lt;implementation-defined character type&gt;</I>;
</UL></TT></PRE>
<PRE><TT><UL>(20)   nul : <B>constant</B> char := char'First;
...
(30)   <B>type</B> wchar_t <B>is</B> <I>&lt;implementation-defined&gt;</I>;
</UL></TT></PRE>
<PRE><TT><UL>(31)   wide_nul : <B>constant</B> wchar_t := wchar_t'First;
</UL></TT></PRE>
<P>The declaration of wide_nul seems to imply that wchar_t
supports the attribute First.  What is the intent?
</P>
<P>If char and/or wchar_t are signed integer types in the interfaced C
implementation, may the Ada implementation reflect that fact by using a
signed representation for char and/or wchar_t?  (Yes.)
</P>
<P>Note that if char and wchar_t have a signed representation, then
char'First and wchar_t'First will not have a zero representation.
Are the constants nul and wide_nul intended to be represented as
zero?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>In package Interfaces.C, the type wchar_t is a discrete type.
The constants nul and wide_nul have implementation-defined
values, which should have a representation of zero.
Types char and wchar_t may use a signed or unsigned
representation.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3(20):   </FONT></B></P>
<UL><UL><PRE><TT>nul : <B>constant</B> char := char'First;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>nul : <B>constant</B> char := <I>implementation-defined</TT></I>;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3(30):   </FONT></B></P>
<UL><UL><PRE><TT><B>type</B> wchar_t <B>is</B> <I>implementation-defined</TT></I>;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>type</B> wchar_t <B>is</B> <I>&lt;implementation-defined discrete type&gt;</TT></I>;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3(31):   </FONT></B></P>
<UL><UL><PRE><TT>wide_nul : <B>constant</B> wchar_t := wchar_t'First;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>wide_nul : <B>constant</B> wchar_t := <I>implementation-defined</TT></I>;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert before  B.3(63):   </FONT></B></P>
<UL><P>An implementation should support the following interface correspondences
between Ada and C.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>The constants nul and wide_nul should have a representation of zero.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is that wchar_t be discrete.
</P>
<P>The type char may have a signed representation.  For example,
the implementation might have:
</P>
<PRE><TT><UL><B>for</B> char <B>use</B> (-128, -127, ..., 127);
</UL></TT></PRE>
<P>In that case, char'First is the wrong value to use for nul;
the intent is that nul be represented as zero.
</P>
<P>Similarly, wchar_t could be an enumeration type with a signed
representation, as for char.  Wchar_t could also be a signed integer
type.  Either way, wchar_t'First is the wrong value to use for wide_nul.
</P>
<P>It is important to allow signed representations of char and wchar_t,
in order to properly match what the C implementation does.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0061"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0061 -  Semantics of Interfaces.C.Strings.To_Char_Ptr when Nul_Check is False</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00140<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>B.3.1(23-24) say:
</P>
<PRE><TT><UL><B>function</B> To_Chars_Ptr (Item      : <B>in</B> char_array_access;
                       Nul_Check : <B>in</B> Boolean := False)
    <B>return</B> chars_ptr;
</UL></TT></PRE>
<P><UL>If Item is null, then To_Chars_Ptr returns Null_Ptr. Otherwise,
if Nul_Check is True and Item.all does not contain nul, then the
function propagates Terminator_Error; if Nul_Check is True and
Item.all does contain nul, To_Chars_Ptr performs a pointer conversion
with no allocation of memory.
</UL></P>
<P>This does not seem to cover the case where Nul_Check is False.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If Nul_Check is False, Interfaces.C.Strings.To_Char_Ptr performs a
pointer conversion with no allocation of memory.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3.1(24):   </FONT></B></P>
<P><UL><UL>
If Item is <B>null</B>, then To_Chars_Ptr returns Null_Ptr. Otherwise,
if Nul_Check is True and Item.<B>all</B> does not contain nul, then the
function propagates Terminator_Error; if Nul_Check is True and
Item.<B>all</B> does contain nul, To_Chars_Ptr performs a pointer conversion
with no allocation of memory.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
If Item is <B>null</B>, then To_Chars_Ptr returns Null_Ptr.
If Item is not <B>null</B>, Nul_Check is True, and Item.<B>all</B> does not
contain nul, then the function propagates Terminator_Error; otherwise
To_Chars_Ptr performs a pointer conversion without allocation of memory.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This obvious omission is hereby corrected (see Summary of Response).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0062"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0062 -  Interfaces.C.Strings.Value raises Constraint_Error when Length is 0</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00139<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>B.3.1(36) says, &quot;The lower bound of the result is 0.&quot;  What happens if
the Length is also 0, so that there is no possible upper bound?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A call to Interfaces.C.Strings.Value with Length 0, as in:
</P>
<P><UL>Value(Item =&gt; X, Length =&gt; 0)
</UL></P>
<P>raises Constraint_Error.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3.1(36):   </FONT></B></P>
<P><UL><UL>
If Item = Null_Ptr then Value(Item) propagates Dereference_Error.
Otherwise Value returns the shorter of two arrays:  the first
Length chars pointed to by Item, and Value(Item). The lower bound of
the result is 0.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
If Item = Null_Ptr, then Value propagates Dereference_Error.
Otherwise, Value returns the shorter of two arrays, either the first Length
chars pointed to by Item, or Value(Item). The lower bound of the result is 0.
If Length is 0, then Value propagates Constraint_Error.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Any attempt to create a null array of type char_array, whose lower bound
is 0, will clearly raise Constraint_Error.  Therefore, &quot;Value(Item =&gt; X,
Length =&gt; 0)&quot; will raise Constraint_Error.  (The standard should have made
this more explicit, however.)
</P>
<P>Note that this is not harmful, since type char_array is supposed to
represent a nul-terminated string, and so should not normally be of
zero length.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0063"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0063 -  Interfaces.C.Strings.Value with Length returning String</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00177<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The definition of the function Interfaces.C.Strings.Value which
takes a chars_ptr and a length, and returning a String, seems
wrong.  As defined, it raises Terminator_Error anytime the
null character is not found before hitting the specified length.
This is because of the definition of To_Ada with Trim_Null =&gt; True.
</P>
<P>Validation test cxb3011 in suite 2.1 seems to presume that no
Terminator_Error should be raised when the input chars_ptr does not have
a null within the specified length.
</P>
<P>What is the intent?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A call to the following function declared in Interfaces.C.Strings:
</P>
<PRE><TT><UL><B>function</B> Value (Item : <B>in</B> chars_ptr; Length : <B>in</B> size_t)
   <B>return</B> String;
</UL></TT></PRE>
<P>is equivalent to:
</P>
<PRE><TT><UL>To_Ada( Value(Item, Length) &amp; nul, Trim_Nul =&gt; True)
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3.1(40):   </FONT></B></P>
<P><UL><UL>
Equivalent to To_Ada(Value(Item, Length), Trim_Nul=&gt;True).</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
Equivalent to To_Ada(Value(Item, Length) &amp; nul, Trim_Nul =&gt; True).</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>B.3.1(40) says:
</P>
<P><UL>Equivalent to To_Ada(Value(Item, Length), Trim_Nul=&gt;True).
</UL></P>
<P>However, this is incorrect.  It makes no sense to trim the nul by
default, and then complain about a missing nul.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0064"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0064 -  Effect of Update(Null_Ptr,...)</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00039<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Does Update raise Dereference_Error if Item = Null_Ptr? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Interfaces.C.Update raises Dereference_Error if Item = Null_Ptr.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3.1(44):   </FONT></B></P>
<P><UL><UL>
This procedure updates the value pointed to by Item, starting at
position Offset, using Chars as the data to be copied into the array.
Overwriting the nul terminator, and skipping with the Offset past the
nul terminator, are both prevented if Check is True, as follows:</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
If Item = Null_Ptr, then Update propagates Dereference_Error. Otherwise,
this procedure updates the value pointed to by Item, starting at
position Offset, using Chars as the data to be copied into the array.
Overwriting the nul terminator, and skipping with the Offset past the
nul terminator, are both prevented if Check is True, as follows:</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Interfaces.C.Update raises Dereference_Error if Item = Null_Ptr.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This seems like the only sensible semantics.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0065"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0065 -  Incorrect example for Interfaces.C.Pointers</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00142<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.3.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>In the example, the usage of &quot;=&quot; in:
</P>
<PRE><TT><UL><B>exit</B> <B>when</B> Element = C.Nul;
</UL></TT></PRE>
<P>is illegal because &quot;=&quot; is not visible for type C.Char.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The example in B.3.2(49) should be corrected to
</P>
<PRE><TT><UL><B>exit</B> <B>when</B> C.&quot;=&quot;(Element, C.nul);
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.3.2(49):   </FONT></B></P>
<UL><UL><PRE><TT>      <B>loop</B>
         Element             := Source_Temp_Ptr.<B>all</B>;
         Target_Temp_Ptr.<B>all</B> := Element;
         <B>exit when</B> Element = C.nul;
         Char_Ptrs.Increment(Target_Temp_Ptr);
         Char_Ptrs.Increment(Source_Temp_Ptr);
      <B>end loop</B>;
   <B>end</B> Strcpy;
<B>begin</B>
   ...
<B>end</B> Test_Pointers;</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>      <B>loop</B>
         Element             := Source_Temp_Ptr.<B>all</B>;
         Target_Temp_Ptr.<B>all</B> := Element;
         <B>exit when</B> C.&quot;=&quot;(Element, C.nul);
         Char_Ptrs.Increment(Target_Temp_Ptr);
         Char_Ptrs.Increment(Source_Temp_Ptr);
      <B>end loop</B>;
   <B>end</B> Strcpy;
<B>begin</B>
   ...
<B>end</B> Test_Pointers;</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The example is wrong and should be corrected.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0066"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0066 -  Correction to the Valid function in COBOL interface</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00071<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The semantics of the Valid function are incorrectly stated.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The Valid function should return False if Item contains leading space
characters, when Format is Unsigned, Leading_Separate, or
Trailing_Separate.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.4(63):   </FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
Format=Unsigned: if Item comprises zero or more leading space
characters followed by one or more decimal digit characters then Valid
returns True, else it returns False.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
Format=Unsigned: if Item comprises one or more decimal digit
characters then Valid returns True, else it returns False.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.4(64):   </FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
Format=Leading_Separate: if Item comprises zero or more
leading space characters, followed by a single occurrence
of the plus or minus sign character, and then one or more
decimal digit characters, then Valid returns True, else it returns False.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
Format=Leading_Separate: if Item comprises a single occurrence of the
plus or minus sign character, and then one or more decimal digit
characters, then Valid returns True, else it returns False.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.4(65):   </FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
Format=Trailing_Separate: if Item comprises zero or more
leading space characters, followed by one or more decimal
digit characters and finally a plus or minus sign
character, then Valid returns True, else it returns False.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
Format=Trailing_Separate: if Item comprises one or more decimal
digit characters followed by a plus or minus sign character, then
Valid returns True, else it returns False.</LI></UL></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This is necessary to match COBOL.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0067"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0067 -  Clarification of result length for conversions in COBOL interface</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00072<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 B.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>In Decimal_Conversions, the functions To_Display (B.4(71)),
To_Packed (B.4(79)), and To_Binary (B.4(87)), do not specify the bounds
of the result. What are these bounds?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>In Decimal_Conversions, the length of the result of To_Display
(B.4(71)), To_Packed (B.4(79)), and To_Binary (B.4(87)) is
Length(Format), and the lower bound is 1.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.4(71):   </FONT></B></P>
<P><UL><UL>
This function returns the Numeric value for Item, represented in
accordance with Format. Conversion_Error is propagated if Num is
negative and Format is Unsigned.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
This function returns the Numeric value for Item, represented in
accordance with Format. The length of the returned value is Length(Format),
and the lower bound is 1. Conversion_Error is propagated if Item is
negative and Format is Unsigned.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.4(79):   </FONT></B></P>
<P><UL><UL>
This function returns the Packed_Decimal value for Item,
represented in accordance with Format. Conversion_Error is
propagated if Num is negative and Format is Packed_Unsigned.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
This function returns the Packed_Decimal value for Item,
represented in accordance with Format. The length of the returned value
is Length(Format), and the lower bound is 1. Conversion_Error is
propagated if Item is negative and Format is Packed_Unsigned.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  B.4(87):   </FONT></B></P>
<P><UL><UL>
This function returns the Byte_Array value for Item, represented
in accordance with Format.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
This function returns the Byte_Array value for Item, represented
in accordance with Format. The length of the returned value is
Length(Format), and the lower bound is 1.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Note that the Length function is overloaded; the Format parameter to
To_Display, To_Packed, or To_Binary resolves which version to use.
</P>
<P>The description of To_Display and To_Packed contains another error: the text
refers to the &quot;value of Num&quot;, but Num is a type, not an object. The intended
reference is to the parameter Item.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0068"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0068 -  Pragma Attach_Handler on nested objects</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00121<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 C.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>C.3.1(7-8) say:
</P>
<P><UL>The Attach_Handler pragma is only allowed immediately within the
protected_definition where the corresponding subprogram is declared.  The
corresponding protected_type_declaration or single_protected_declaration
shall be a library level declaration.
</UL></P>
<P><UL>The Interrupt_Handler pragma is only allowed immediately within a
protected_definition.  The corresponding protected_type_declaration shall be
a library level declaration.  In addition, any object_declaration of such a
type shall be a library level declaration.
</UL></P>
<P>The AARM C.3.1(7.a) adds:
</P>
<P><UL>Discussion: In the case of a protected_type_declaration, an
object_declaration of an object of that type need not be at library
level.
</UL></P>
<P>Thus, nested objects are not allowed in the Interrupt_Handler case, but
they are allowed in the Attach_Handler case.
</P>
<P>C.3.1(12) says:
</P>
<P><UL>When a protected object is
finalized, for any of its procedures that are attached to interrupts, the
handler is detached.  If the handler was attached by a procedure in the
Interrupts package or if no user handler was previously attached to the
interrupt, the default treatment is restored.  Otherwise, that is, if an
Attach_Handler pragma was used, the previous handler is restored.
</UL></P>
<P>and the AARM C.3.1(12.a) adds:
</P>
<P><UL>Discussion:  Since only library-level protected procedures can
be attached as handlers using the Interrupts package, the
finalization discussed above occurs only as part of the finalization
of all library-level packages in a partition.
</UL></P>
<P>Thus, in the Attach_Handler case, when the object is finalized, the
&quot;previous handler&quot; is restored.
</P>
<P>What is meant by &quot;previous handler&quot; here?  Does this feature make sense
in a multi-tasking situation?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A program execution is erroneous if the handlers for a given interrupt
attached via pragma Attach_Handler are not attached and detached in a
stack-like (LIFO) order.  In particular, when a protected object is
finalized, if any of its procedures are attached to interrupts via
pragma Attach_Handler, then if the most recently attached handler for
the same interrupt is not the same as the one that was attached at the
time the protected object was created, then execution is erroneous.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  C.3.1(12):   </FONT></B></P>
<UL><P>When a protected object is finalized, for any of its procedures that are
attached to interrupts, the handler is detached. If the handler was attached
by a procedure in the Interrupts package or if no user handler was previously
attached to the interrupt, the default treatment is restored. Otherwise,
that is, if an Attach_Handler pragma was used, the previous handler is
restored.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>When a protected object is finalized, for any of its procedures that are
attached to interrupts, the handler is detached. If the handler was attached by
a procedure in the Interrupts package or if no user handler was previously
attached to the interrupt, the default treatment is restored. If an
Attach_Handler pragma was used and the most recently attached handler
for the same interrupt is the same as the one that was attached at the time the
protected object was initialized, the previous handler is restored.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  C.3.1(14):   </FONT></B></P>
<UL><P>If the Ceiling_Locking policy (see D.3) is in effect and an interrupt is
delivered to a handler, and the interrupt hardware priority is higher than
the ceiling priority of the corresponding protected object, the execution of
the program is erroneous.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>If the handlers for a given interrupt attached via pragma Attach_Handler are
not attached and detached in a stack-like (LIFO) order, program execution is
erroneous. In particular, when a protected object is finalized, the execution
is erroneous if any of the procedures of the protected object are attached to
interrupts via pragma Attach_Handler and the most recently attached handler for
the same interrupt is not the same as the one that was attached at the time the
protected object was initialized.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The notion of restoring the &quot;previous handler&quot; only makes sense if
objects are created and destroyed in a stack-like (LIFO) manner.  In a
multi-tasking program, it is possible to do otherwise -- for example,
task A declares an object, then task B declares an object, then task A
completes, destroying the first object, then task B completes,
destroying the second object.
</P>
<P>Several options exist:
</P>
<P>Option 1: require every protected object with an Attach_Handler pragma
to be at library level.  This is clearly not what the standard says.  It
doesn't completely solve the problem, either -- one could create two
objects on the heap, and call an instance of Unchecked_Deallocation on them
in a non-LIFO order.
</P>
<P>Option 2: define &quot;previous handler&quot; to be &quot;the handler that was attached
at the time the protected object was initialized&quot;.  If that handler no
longer exists, execution becomes erroneous.  This means that if the
programmer uses a LIFO order, it all works.  If the programmer uses a
non-LIFO order, handlers may get restored in a &quot;surprising&quot; order, and
in <I>some</I> cases, erroneous execution will result.
</P>
<P>Note that it is possible to have a LIFO order, even in a multi-tasking
program.  For example, first declare an object at library level.  Create
lots of tasks.  Then, at some point, one of the tasks declares another
object.  Clearly, this second object will be finalized before the first
one, which is what we want.
</P>
<P>The implementation in this case is not so hard: store a pointer to the
previous handler in the protected object, and blindly restore it on
finalization.
</P>
<P>Option 3: define the &quot;previous handler&quot; to be the one that was attached
just before the current handler was attached.  Again, execution is
erroneous if one tries to restore a handler that no longer exists.
Again, the implementation is not so hard: keep a stack of handlers.
When a protected object is finalized, blindly pop one item off the
stack, whether or not the protected object on the stack corresponds to
the current handler.
</P>
<P>If the programmer ensures a LIFO order, then the second and third
possibilities are equivalent.
</P>
<P>Option 4: an exception is raised if a LIFO order is not obeyed.  That
is, when a protected object is finalized, a check is made that this
protected object corresponds to the currently-attached handler; if not,
an exception is raised.  In this case, the implementation can be as for
the second <I>or</I> the third possibility, since they are equivalent.
</P>
<P>Option 5: same as the fourth, except that execution becomes erroneous
instead of raising an exception.  The implementation is the same as for
the fourth possibility, except that the check is omitted.
</P>
<P>We choose Option 5.  It is the programmer's responsibility to maintain
LIFO order; otherwise execution is erroneous.  We do not wish to impose
overhead on implementations to check for LIFO order.  If an
implementation wishes to check, it can raise an exception as soon as
LIFO order is disobeyed (thus implementing Option 4).  We also do not
wish to be restrictive, as would happen with Option 1.
</P>
<P>Upon finalization, an implementation may restore either the handler that
was installed at the time the current object was initialized, or the
handler that was most recently installed before the current one.  For
all non-erroneous situations, these two are the same handler.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0069"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0069 -  Parameterless_Handler values designating default treatment</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00166<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 C.3.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>C.3.2(18) says, &quot;The Exchange_Handler procedure operates in the same
manner as Attach_Handler with the addition that the value returned in
Old_Handler designates the previous treatment for the specified
interrupt.&quot;  This would seem to suggest that if Exchange_Handler is
invoked while the default treatment is still in force, the value in
Old_Handler can be dereferenced, with the dereference denoting a
parameterless protected procedure that can be called to obtain the
default treatment.  Is this the intent? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>When a default treatment is in effect for an interrupt, the value
returned by Current_Handler is null.  Likewise, the value returned
in Old_Handler by the Exchange_Handler procedure is null if it is
invoked while the default treatment is in force for the specified
interrupt.
</P>
<P>Furthermore, the value returned by Current_Handler and in
Old_Handler must be null whenever the treatment is not a
user-defined handler.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  C.3.2(16):   </FONT></B></P>
<UL><P>The Current_Handler function returns a value that represents the
attached handler of the interrupt. If no user-defined handler is attached to
the interrupt, Current_Handler returns a value that designates the default
treatment; calling Attach_Handler or Exchange_Handler with this value
restores the default treatment.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The Current_Handler function returns a value that represents the
attached handler of the interrupt. If no user-defined handler is attached to
the interrupt, Current_Handler returns <B>null</B>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  C.3.2(18):   </FONT></B></P>
<UL><P>The Exchange_Handler procedure operates in the same manner as Attach_Handler
with the addition that the value returned in Old_Handler designates
the previous treatment for the specified interrupt.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The Exchange_Handler procedure operates in the same manner as Attach_Handler
with the addition that the value returned in Old_Handler designates
the previous treatment for the specified interrupt. If the previous treatment
is not a user-defined handler, <B>null</B> is returned.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>A key fact here is that a &quot;treatment&quot; of an interrupt (whether
default or user-defined) is not limited to execution of a handler,
and even if the treatment is to call a handler the handler may be
something other than a parameterless protected procedure.
</P>
<P>There may be external mechanisms (perhaps in hardware or in an
operating system) that can mediate the delivery of a signal in a
way that is distinct from executing a handler procedure.  For
example, in the UNIX environment the concept of interrupt
corresponds to that of a &quot;signal&quot;; the default treatments for
signals include ignoring (discarding) the signal or performing
job-control functions including terminating the process (with or
without memory dump), stopping the process, and continuing a
stopped process.  Even with hardware interrupts, the default
treatment that is initially in place when a program starts up is
unlikely to be calling an Ada protected procedure.
</P>
<P>The intent of the International Standard is to allow treatments other
than parameterless protected procedures as defaults is expressed
clearly in C.3(5):
</P>
<P><UL>Each interrupt has a default treatment which determines the
system's response to an occurrence of that interrupt when no
user-defined handler is attached.  The set of possible default
treatments is implementation defined, as is the method (if one
exists) for configuring the default treatments for interrupts.
</UL></P>
<P>Note that the default treatment of an interrupt is not even
required to be static.  It is possible that an implementation or
underlying operating system may have a mechanism that modifies the
default treatment of an interrupt (or signal) while a program is
running.
</P>
<P>C.3(29) gives implementation advice as to examples of possible
default treatments, but does not limit them:
</P>
<P><UL>(1) The default treatment for an interrupt can be to keep the
interrupt pending or to deliver it to an implementation-defined
handler.  Examples of actions that an implementation-defined
handler is allowed to perform include aborting the partition,
ignoring (i.e., discarding occurrences of) the interrupt, or
queuing one or more occurrences of the interrupt for possible
later delivery when a user-defined handler is attached to that
interrupt.
</UL></P>
<P>Moreover, the intent of the standard is to allow user-specified
handlers that are not parameterless protected procedures, as
specified in C.3(26)
</P>
<P><UL>Other forms of handlers are allowed to be supported, in which
case, the rules of this subclause should be adhered to.
</UL></P>
<P>For example, it would be legal for an implementation to define a
way to attach an ordinary procedure to an interrupt, or in the
case of UNIX signals to attach ordinary procedures of several
forms -- one with no parameter, one with a single, signal
parameter, one with a signal parameter and a context parameter,
etc.
</P>
<P>This is emphasized in C.3.1(19):
</P>
<P><UL>Notwithstanding what this subclause says elsewhere, the
Attach_Handler and Interrupt_Handler pragmas are allowed to be
used for other, implementation defined, forms of interrupt
handlers.
</UL></P>
<P>and again in C.3.2(25):
</P>
<P><UL>If implementation-defined forms of interrupt handler
procedures are supported, such as protected procedures with
parameters, then for each such form of a handler, a type
analogous to Parameterless_Handler should be specified in a
child package of Interrupts, with the same operations as in the
predefined package Interrupts.
</UL></P>
<P>This means that if an implementation supports handlers or other
interrupt treatments (whether default or user-specified)
there will be situations in which the semantics of the operations
defined in Ada.Interrupts for parameterless protected procedure
handlers must be modified to take into account these other forms
of treatments or handlers.
</P>
<P>If Ada.Interrupts.Current_Handler or
Ada.Interrupts.Exchange_Handler is called in a situation where the
treatment in force for a given interrupt (whether default or
user-specified) does not correspond to any parameterless protected
procedure, the operation cannot return a value that designates a
callable parameterless protected procedure.
</P>
<P>Note that even if we were willing to require an implementation to
create a &quot;fake&quot; Ada protected procedure, so as to be able to
return a reference to a callable protected procedure, we have
situations where the default treatment cannot be simulated by a
protected procedure.
</P>
<P>The intent of this section was that the value returned by
Current_Handler or in Old_Handler may &quot;represent&quot; a handler or
other treatment that is not a parameterless protected procedure,
e.g., it might be an integer code for a default treatment or the
address of some other kind of handler, unchecked-converted to the
type Parameterless_Handler.  The notion was that such a value
might not be usable for calling the handler directly from the
application, but could meaningfully and safely be used to restore
the old treatment or handler, by passing it back as New_Handler in
a call to Exchange_Handler.  This provides the capability for a
user to safely install a handler, and then later restore the
previous treatment, without needing to worry about whether the
previous treatment is a parameterless protected procedure.
</P>
<P>This intent is reflected in the first sentence of C.3.2(16),
which says Current_Handler returns a value that &quot;represents&quot; the
attached handler, rather than &quot;designates&quot;.  It is unfortunate
that the word &quot;designates&quot; was inadvertently substituted in the
second sentence, where the case of there being no user-defined
handler is discussed.
</P>
<P>Original intent aside, the question does raise a valid pragmatic
issue.  There are situations where it is desirable to allow the
&quot;cascading&quot; of handlers, i.e., when a new handler is installed
using Exchange_Handler, the new handler may use the previous
handler (returned in the Old_Handler parameter) to call the
previous hander -- for those situations where the previous handler
was a parameterless protected procedure.  However, to cascade
handlers in this fashion, the application must know that there is
a callable handler and the parameter profile of the handler.
</P>
<P>It might be nice if there were a &quot;portable&quot; way for an application
to determine whether the value returned in Old_Handler or by
Current_Handler is one that can be dereferenced to call a
parameterless protected procedure, as in the handler-cascading
model.  The standard itself does not explicitly specify how this can be
determined, but it can be interpreted in a way that may suffice.
</P>
<P>C.3.2(17) does require that the null access value can be
used to specify the default treatment for an interrupt:
</P>
<P><UL>The Attach_Handler procedure attaches the specified handler
to the interrupt, overriding any existing treatment (including a
user handler) in effect for that interrupt.  If New_Handler is
null, the default treatment is restored. ...
</UL></P>
<P>This binding interpretation extrapolates from the above to
conclude that the value returned by Current_Handler, and the value
returned in Old_Handler by Exchange_Handler, must be the null
access value whenever the treatment that is in force for the
given signal is the default treatment.  It further extrapolates to
conclude that the null access value must be returned whenever the
treatment is not a user-installed handler.  It follows that for
implementations that support only parameterless protected
procedures as handlers, these operations return only the null
value and access values that can be used to call a parameterless
protected procedure.
</P>
<P>This provides a way to safely cascade user-installed handlers,
provided the application uses only parameterless procedures as
handlers.
</P>
<P>This is a compromise.  It does not provide the full capability
that the original question hoped for; i.e., there is no way to
&quot;call&quot; the default treatment.  Likewise, if the implementation
supports other forms of handlers, and the application uses them,
there remains the possibility that the value returned by
Current_Handler or in Old_Handler represents a handler that is not
a parameterless protected procedure, and so it would be erroneous
to call it without parameters.  On the other hand, it would still
be safe to use Exchange_Handler to restore such a handler.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0070"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0070 -  Abort_Task has a parameter of mode 'in'</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00101<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 C.7.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>C.7.1(3) shows procedure Abort_Task taking a parameter of mode 'in out'.
Is this correct?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Task_Identification.Abort_Task takes a parameter of mode 'in':
</P>
<PRE><TT><UL><B>procedure</B> Abort_Task (T : <B>in</B> Task_Id);
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">In  C.7.1(3) replace:   </FONT></B></P>
<UL><UL><PRE><TT><B>procedure</B> Abort_Task   (T : <B>in out</B> Task_Id);</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>procedure</B> Abort_Task   (T : <B>in</B> Task_Id);</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Abort_Task does not modify its parameter, which is a Task_ID.
Therefore, its parameter should be of mode 'in'.
</P>
<P>Furthermore, if the parameter is of mode 'in out', then one cannot pass
a function call or a constant.  For example, Abort_Task(Current_Task)
should be allowed.  For another example, the following ought to be
allowed:
</P>
<PRE><TT><UL><B>type</B> Task_ID_Array <B>is</B> <B>array</B> (Natural <B>range</B> &lt;&gt;) <B>of</B> Task_ID;
<B>procedure</B> Abort_Some_Tasks(Tasks: Task_ID_Array) <B>is</B>
<B>begin</B>
    <B>for</B> I <B>in</B> Tasks'<B>range</B> <B>loop</B>
        Abort_Task(Tasks(I));
    <B>end</B> <B>loop</B>;
<B>end</B> Abort_Some_Tasks;
...
Abort_Some_Tasks((This_Task_ID, That_Task_ID, The_Other_Task_ID));
</UL></TT></PRE>
<P>Hence, this parameter should be of mode 'in'.
</P>
<P>Note that Abort_Task is not analogous to Unchecked_Deallocation.  After
a call to an instance of Unchecked_Deallocation, the designated object
ceases to exist, and any reference to it would be erroneous; therefore
it makes sense for Unchecked_Deallocation to set the access object to
null.  However, after a call to Abort_Task, the task object continues to
exist, and the task might even keep running for a while.  Therefore, it
does not make sense for Abort_Task to set its parameter to Null_Task_ID.
Note that it is harmless to abort the same task twice -- either with an
abort_statement, or with Abort_Task.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0071"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0071 -  Recursive use of task attributes</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00165<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 C.7.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>C.7.2(16) says, in full, &quot;The implementation shall perform
each of the above operations for a given attribute of a given task
atomically with respect to any other of the above operations for the
same attribute of the same task.&quot;
</P>
<P>Let us call an (attribute, task) pair a 'cell' for convenience.  The
atomicity requirement cannot be met if an operation on a cell
recursively invokes an operation on the same cell: an operation cannot
be atomic with respect to another operation embedded within itself.
</P>
<P>What is the intent?
</P>
<P>These operations can be recursive, because they perform finalization and
assignment, which might invoke a user-defined Finalize or Adjust
procedure, which might then recursively call the operation in question.
</P>
<P>Here is an example of a recursive call to Set_Value:
</P>
<PRE><TT><UL><B>with</B> Ada.Finalization; <B>use</B> Ada.Finalization;
<B>with</B> Ada.Task_Attributes;
<B>package</B> An_Attr <B>is</B>
  <B>type</B> Attr <B>is</B> <B>new</B> Controlled <B>with</B> <B>record</B>
      N : Integer;
    <B>end</B> <B>record</B>;
  <B>procedure</B> Adjust(X : <B>in</B> <B>out</B> Attr);
</UL></TT></PRE>
<PRE><TT><UL>  <B>package</B> Ops <B>is</B> <B>new</B> Ada.Task_Attributes(Attr,
        Initial_Value =&gt; (Controlled <B>with</B> 0));
</UL></TT></PRE>
<PRE><TT><UL><B>end</B> An_Attr;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Ada.Text_IO; <B>use</B> Ada.Text_IO;
<B>package</B> <B>body</B> An_Attr <B>is</B>
  Depth : Natural := 0;
</UL></TT></PRE>
<PRE><TT><UL>  <B>procedure</B> Adjust(X : <B>in</B> <B>out</B> Attr) <B>is</B>
  <B>begin</B>
    Put_Line((1..2*Depth =&gt; ' ') &amp; &quot;Adjust called&quot;);
    Depth := Depth + 1;
    <B>if</B> Depth &lt;= 3 <B>then</B>
      Put_Line((1..2*Depth =&gt; ' ') &amp; &quot;calling Set_Value...&quot;);
      Ops.Set_Value((Controlled <B>with</B> Depth));
    <B>end</B> <B>if</B>;
  <B>end</B> Adjust;
</UL></TT></PRE>
<PRE><TT><UL><B>end</B> An_Attr;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Ada.Finalization; <B>use</B> Ada.Finalization;
<B>with</B> An_Attr;
<B>procedure</B> A_Prog <B>is</B>
<B>begin</B>
  An_Attr.Ops.Set_Value((Controlled <B>with</B> 17)); -- One call
<B>end</B> A_Prog;
</UL></TT></PRE>
<P>Finally, what happens if one of the operations of the package is concurrently
executed with an access via an attribute handle?  Is there an atomicity
requirement on the latter as well?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If the package Ada.Task_Attributes is instantiated with a controlled
type and the controlled type has user-defined Adjust or Finalize
operations that in turn access task attributes via instantiated
interfaces of this generic package, then a call of Set_Value of the
instantiated package constitutes a bounded error. The call may perform
as expected or it may result in a deadlock of the calling task and
subsequently of the entire partition or of other tasks accessing task
attributes.
</P>
<P>Accesses via an Attribute_Handle (as obtained by calling the function
Reference) are not subject to the atomicity requirement of C.7.2(16).
Such accesses, if concurrent with each other or with the execution of
any of the subprograms provided by the package, are erroneous.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  C.7.2(13):   </FONT></B></P>
<UL><P>For all the operations declared in this package, Tasking_Error is raised
if the task identified by T is terminated. Program_Error is raised if the
value of T is Null_Task_ID.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P><I><FONT SIZE=-2>Bounded (Run-Time) Errors</FONT></I><BR>
If the package Ada.Task_Attributes is instantiated with a controlled
type and the controlled type has user-defined Adjust or Finalize
operations that in turn access task attributes by any of the above
operations, then a call of Set_Value of the instantiated package
constitutes a bounded error. The call may perform as expected or
may result in forever blocking the calling task and subsequently some
or all tasks of the partition.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Insert after  C.7.2(15):   </FONT></B></P>
<UL><P>If a value of Task_ID is passed as a parameter to any of the operations
declared in this package and the corresponding task object no longer exists,
the execution of the program is erroneous.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>Accesses to task attributes via a value of type Attribute_Handle are
erroneous if executed concurrently with each other or with calls of
any of the operations declared in package Task_Attributes.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  C.7.2(16):   </FONT></B></P>
<UL><P>The implementation shall perform each of the above operations for a
given attribute of a given task atomically with respect to any other of the
above operations for the same attribute of the same task.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>For a given attribute of a given task, the implementation shall perform the
operations declared in this package atomically with respect to any of these
operations of the same attribute of the same task.
The granularity of any locking mechanism necessary to achieve such
atomicity is implementation defined.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A deadlock cannot be sensibly avoided when a recursive access via one
of the interfaces of the package occurs to the same task attribute of
the same task.  Accesses via an Attribute_Handle are not subjected to
the same atomicity and hence locking requirement. Therefore there are
already dangerous situations and it seems inappropriate to impose a
major performance penalty on some implementations in order to narrow
only the already sufficiently rare deadlocking cases as much as
possible.
</P>
<P>A more liberal interpretation is recommended that allows
implementations to choose the most appropriate lock granularity. A
nested access to a task attribute from within a Finalize or Adjust
procedure becomes a bounded error. Depending on the lock granularity,
the initiating call of Set_Value will either deadlock or perform its
nested accesses as expected. Concurrent accesses via Attribute_Handles
are deemed erroneous.
</P>
<P>The summary of this issue specifies these semantics in more detail.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The atomicity of the operations will require some locking mechanism to
prevent concurrent accesses to the same task attribute of a given
task. C.7.2(16) seems to imply that an individual lock is provided
for each attribute of each task. However, obtaining a lock can be a
rather expensive operation, particularly for implementations that
utilize the locking primitives of an underlying operating system.
</P>
<P>If the attribute does not involve controlled types with user-defined
Adjust and Finalize routines, then a single run-time lock suffices
to achieve the semantics of C.7.2(16).
</P>
<P>If the attribute is of a controlled type or has components of a controlled
type, then the implicitly invoked user-defined Adjust or Finalize routines
are presently not forbidden to call on operations of this package for other
task attributes or even, rather pathologically, for the same task attribute
of the given task. Whatever locking strategy is applied, the latter will lead
to a deadlock. The former can lead to a deadlock if the granularity of the
lock is any larger than on single attributes of any task, e.g., a lock per
task or a global run-time lock.
</P>
<P>It seems unwise to require all implementations to provide a potentially
expensive very fine-grained locking on attributes merely to guard against
the fairly rare situation, in which
</P>
<P><UL>- a controlled type is chosen for a task attribute, and
</UL></P>
<P><UL>- the Adjust or Finalize operation of the controlled type
calls on operations of this package in turn to read or modify
task attributes.
</UL></P>
<P>Also, the case of a recursive access to the same attribute of the same task
will deadlock anyway.
</P>
<P>The use of attribute handles is not protected by any atomicity
requirement in the standard, so that their concurrent use must be deemed
erroneous.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0072"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0072 -  Priority changes due to Set_Priority and Hold are not transitive</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00092<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 D.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>D.1(21-22) say:
</P>
<P><UL>During activation, a task being activated inherits the active
priority of the its activator (see 9.2).
</UL></P>
<P><UL>During rendezvous, the task accepting the entry call inherits the
active priority of the caller (see 9.5.3).
</UL></P>
<P>But this implies that if Set_Priority or Hold is called on a task,
other tasks that are currently inheriting priority from the first
task, would have to have their active priorities modified.
Is this asynchronous priority inheritance the intent?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If Set_Priority or Hold is called on a task, other tasks that are
currently inheriting priority from the first task do not have their
active priorities modified.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.1(21):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
During activation, a task being activated inherits the active
priority of the its activator (see 9.2).</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
During activation, a task being activated inherits the active
priority that its activator (see 9.2) had at the time the
activation was initiated.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.1(22):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
During rendezvous, the task accepting the entry call inherits the
active priority of the caller (see 9.5.3).</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
During rendezvous, the task accepting the entry call inherits the
priority of the entry call (see 9.5.3 and D.4).</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>D.1(21-22) seem to imply that asynchronous priority inheritance is
required, meaning that when Set_Priority is called on a task, the active
priority of other tasks must be modified.  It was clearly not the intent
to require asynchronous priority inheritance.  Set_Priority is
inherently asynchronous -- the task being affected may be doing anything
when Set_Priority is called.  However, we do not wish to require this
asynchronous behavior to extend to <I>other</I> tasks -- asynchronous
priority inheritance -- because it would be an implementation burden, and
it is not clearly useful, given that priority inheritance is not
uniformly transitive in all cases.
</P>
<P>D.4(8-11) support the above as the &quot;intent&quot;. In particular, D.4(11) says:
</P>
<P><UL>When the base priority of a task is set (see D.5), if the task is
blocked on an entry call, and the call is queued, the priority of
the call is updated to the new active priority of the calling
task.  This causes the call to be removed from and then
reinserted in the queue at the new active priority.
</UL></P>
<P>If Set_Priority on an entry caller were really intended to affect the
active priority of a rendezvous-in-progress, then why would D.4(11) go
to the trouble to say &quot;and the call is queued&quot;?  This intent is
also supported by the NOTE in D.11(17):
</P>
<P><UL>If a task becomes held while waiting (as a caller) for a
rendezvous to complete, the active priority of the accepting
task is not affected.
</UL></P>
<P>There are two possible solutions:
</P>
<P><UL>Alternative 1: Asynchronous priority inheritance does not happen.
This is the interpretation given in the summary and wording above.
In this alternative, if Set_Priority is applied to a task, then
other tasks that are currently inheriting priority from the first
task do not have their active priorities modified.
</UL></P>
<P><UL>Alternative 2: Asynchronous priority inheritance is not required,
but an implementation may do it.  In this alternative, when
Set_Priority is applied to a task, it is implementation-defined
whether or not other tasks that are currently inheriting priority
from the first task have their active priorities modified.
</UL></P>
<P>Inheritance due to activation and rendezvous should be treated the same,
and for rendezvous, it shouldn't make a difference whether the call is
the trigger of an ATC or not.  Both alternatives obey this principle.
</P>
<P>The advantage of Alternative 1 is that it requires more uniformity
across implementations.  However, Alternative 2 seems to allow a fairly
harmless implementation variation.  Clearly, Alternative 2 is not harder
to implement than Alternative 1.  It is conceivable that Alternative 2
might be easier in some environments.
</P>
<P>Note that either alternative allows an implementation to support
asynchronous priority inheritance as a non-standard policy.
Alternative 1 implies that if asynchronous priority inheritance is
supported, the implementation must support two mechanisms, whereas
Alternative 2 allows the asynchronous case to be the only one.
</P>
<P>The implementation variation allowed by Alternative 2 is not entirely
harmless.  If a program is written assuming transitive priority
inheritance, it could miss real-time deadlines when ported to an
implementation that does not support transitive priority inheritance.
When porting in the other direction, a working program could fail
because of a violation of the ceiling rule in D.3(13):
</P>
<P><UL>When a task calls a protected operation, a check is made that its
active priority is not higher than the ceiling of the
corresponding protected object; Program_Error is raised if this
check fails.
</UL></P>
<P>In fact, Alternative 2 would allow an implementation to cause a
&quot;retroactive&quot; violation of D.3(13).  Presumably, the implementation
would have to resolve this difficulty if it chose to implement
asynchronous priority inheritance.  Note that D.5(10) only talks about
the task being directly affected, not other inheritors:
</P>
<P><UL>Setting the task's base priority to the new value takes place as
soon as is practical but not while the task is performing a
protected action.
</UL></P>
<P>Presumably, the implementation would extend this deferral of priority
changes to apply to the inheritors as well.
</P>
<P>The discussion above refers to Set_Priority.  The same arguments apply
to Hold -- the whole point of defining Hold in terms of priorities was
to avoid having to spell out all kinds of interactions between Hold and
other tasking features.
</P>
<P>Presumably, programs will not typically use both Hold and other features
(like rendezvous) together.  Therefore, the efficiency of Hold on a task
in rendezvous doesn't matter.  It's just important that there be little
or no distributed overhead (in either direction).
</P>
<P>Note that the issue does not arise for protected entry calls (the case
in D.1(23)), because ceiling priorities can never change.
</P>
<P>Given the advantages of implementation uniformity, Alternative 1 is
chosen.  Implementations that wish to support asynchronous priority
inheritance must do so via a non-standard policy.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0073"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0073 -  Pragma Locking_Policy cannot be in a program unit</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00091<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 D.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>D.3(6) says:
</P>
<P><UL>If no Locking_Policy pragma <I>appears in</I> any of the program units
comprising a partition, the locking policy for that partition, as well
as the effect of specifying either a Priority or Interrupt_Priority
pragma for a protected object, are implementation defined.
[Emphasis added.]
</UL></P>
<P>But Locking_Policy is a configuration pragma, and configuration pragmas
do not &quot;appear in&quot; program units.  What is the intent?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If no Locking_Policy pragma applies to any of the program units
comprising a partition, the locking policy for that partition, as well
as the effect of specifying either a Priority or Interrupt_Priority
pragma for a protected object, are implementation defined.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">In  D.3(6) replace:   </FONT></B></P>
<UL><P>If no Locking_Policy pragma appears in any of the program units comprising
a partition, the locking policy for that partition, as well as the effect
of specifying either a Priority or Interrupt_Priority pragma for a protected
object, are implementation defined.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>If no Locking_Policy pragma applies to any of the program units comprising
a partition, the locking policy for that partition, as well as the effect
of specifying either a Priority or Interrupt_Priority pragma for a protected
object, are implementation defined.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is as stated under &quot;wording&quot;.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0074"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0074 -  Number of queuing policies defined</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00068<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 D.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>D.4(1) says &quot;It also defines one such policy.&quot; But the language defines two
such policies. What is meant here?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>D.4 defines <I>two</I> language-defined policies.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.4(1):   </FONT></B></P>
<UL><P>This clause specifies a mechanism for a user to choose an entry <I>queuing
policy</I>. It also defines one such policy. Other policies are implementation
defined.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>This clause specifies a mechanism for a user to choose an entry <I>queuing
policy</I>. It also defines two such policies. Other policies are implementation
defined.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The wording for D.4(1) is hereby corrected.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This is just an editing error. Obviously, the language defines two policies
(FIFO_Queuing and Priority_Queuing).
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0075"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0075 -  Priority changes in abortable part</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00205<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 D.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>If Set_Priority is called in the abortable part, is the priority of the
triggering entry call updated? (No.)  D.4(10) does not apply (because the
base priority of the task is set), so it appears that the update must
occur (because either D.4(10) or D.4(11) must apply). But there is a
validation test which requires otherwise.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For the priority queuing policy, if the base priority is changed in an
abortable part while a triggering entry call is queued, the priority of
the entry call is not affected. (That is, the rule of D.4(10) applies.)
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.4(10):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
After a call is first queued, changes to the active priority of a
task do not affect the priority of the call, unless the base
priority of the task is set.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
After a call is first queued, changes to the active priority of a task
do not affect the priority of the call, unless the base priority of the task is
set while the task is blocked on an entry call.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The language designers did not want D.4(11) to apply in this case. This
is supported by the use of the phrase &quot;if the task is blocked on an entry
call&quot; in D.4(11) -- the task making a triggering entry call is not blocked.
It is further supported by the lengthy discussion in the AARM on this
very topic (AARM D.4(11.a-11.f)).
</P>
<P>However, the language designers failed to note that the wording of D.4(10)
prevents it from applying in this case as well. The intent was that D.4(10)
would apply to all entry calls unless D.4(11) applied.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0076"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0076 -  Pragma Restrictions(Max_Tasks, Max_Asynchronous_Select_Nesting)</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00067<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 D.7</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The Real-Time Systems annex says in D.7(15) (of the Max_Tasks and
Max_Asynchronous_Select_Nesting restrictions):
</P>
<P><UL>If the following restrictions are violated, the behavior is
implementation defined.  If an implementation chooses to detect such a
violation, Storage_Error should be raised.
</UL></P>
<P>The Safety and Security annex says in H.4(2):
</P>
<P><UL>The following restrictions, the same as in D.7, apply in this Annex:
No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation,
Max_Task_Entries is 0, Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is
0.  The last three restrictions are checked prior to program execution.
</UL></P>
<P>Suppose an implementation complies with both annexes.  Is the following
example legal?  (No.)
</P>
<PRE><TT><UL><B>pragma</B> Restrictions (Max_Tasks =&gt; 0);
<B>procedure</B> main <B>is</B>
<B>begin</B>
   <B>if</B> false <B>then</B>
      <B>declare</B>
         <B>task</B> x <B>is</B> -- Legal?  (No.)
         ...
   <B>end</B> <B>if</B>;
<B>end</B> main;
</UL></TT></PRE>
<P>What does it mean that the restriction is &quot;checked prior to program
execution&quot;?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For a pragma Restrictions(Max_Tasks =&gt; 0), task creation is illegal, for
both the Real-Time Systems annex and the Safety and Security annex.  Similarly,
for a pragma Restrictions(Max_Asynchronous_Select_Nesting =&gt; 0),
asynchronous_selects are illegal, for both of these annexes.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Delete  D.7(15):  </FONT></B></P>
<UL><P>If the following restrictions are violated, the behavior is
implementation defined. If an implementation chooses to detect such a
violation, Storage_Error should be raised.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.7(17):   </FONT></B></P>
<P><UL><DL>
<DT>Max_Storage_At_Blocking<DD>
Specifies the maximum portion (in storage elements) of a
task's Storage_Size that can be retained by a blocked task.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>Max_Storage_At_Blocking<DD>
Specifies the maximum portion (in storage elements) of a task's Storage_Size
that can be retained by a blocked task. If an implementation chooses to detect
a violation of this restriction, Storage_Error should be raised; otherwise,
the behavior is implementation defined.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.7(18):   </FONT></B></P>
<P><UL><DL>
<DT>Max_Asynchronous_Select_Nesting<DD>
Specifies the maximum dynamic nesting level of <FONT FACE="Arial, Helvetica">asynchronous_select</FONT>s.
A value of zero prevents the use of any <FONT FACE="Arial, Helvetica">asynchronous_select</FONT>.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>Max_Asynchronous_Select_Nesting<DD>
Specifies the maximum dynamic nesting of <FONT FACE="Arial, Helvetica">asynchronous_select</FONT>s. A value of
zero prevents the use of any <FONT FACE="Arial, Helvetica">asynchronous_select</FONT> and, if a program
contains an <FONT FACE="Arial, Helvetica">asynchronous_select</FONT>, it is illegal. If an implementation
chooses to detect a violation of this restriction for values other than zero,
Storage_Error should be raised; otherwise, the behavior is implementation
defined.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.7(19):   </FONT></B></P>
<P><UL><DL>
<DT>Max_Tasks<DD>
Specifies the maximum number of task creations that may be executed over the
lifetime of a partition, not counting the creation of the environment task.</DL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><DL>
<DT>Max_Tasks<DD>
Specifies the maximum number of task creations that may be executed over the
lifetime of a partition, not counting the creation of the environment task. A
value of zero prevents any task creation and, if a program contains a task
creation, it is illegal. If an implementation chooses to detect a violation
of this restriction for values other than zero, Storage_Error should be raised;
otherwise, the behavior is implementation defined.</DL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>An implementation conforming to the Safety and Security annex must support a pragma
Restrictions(Max_Tasks =&gt; E), where E is a static expression whose value
is zero.  If such a pragma applies to a given compilation unit, then for
an implementation conforming to the Real-Time Systems or Safety and Security
annex (or both), the compilation unit is illegal if it contains an
object_declaration or allocator, where the type of the created object is a
task type, or is a composite type with some subcomponent type that is a
task type.
</P>
<P>An implementation conforming to the Safety and Security annex must support a pragma
Restrictions(Max_Asynchronous_Select_Nesting =&gt; E), where E is a static
expression whose value is zero.  If such a pragma applies to a given
compilation unit, then for an implementation conforming to the Real-Time Systems
or Safety and Security annex (or both), the compilation unit is illegal if it
contains an asynchronous_select.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is that it should be possible for a single implementation to
comply with all of the Specialized Needs Annexes.  Therefore, there
cannot be contradictory requirements in two different Specialized Needs
Annexes.
</P>
<P>&quot;Max_Tasks is 0&quot; should be interpreted to mean that a static expression
is given, and its value is zero.  Clearly, we cannot require
compile-time detection unless the expression is static.  But we don't
want to interpret &quot;is 0&quot; to mean that it must be a literal with value
zero, or a literal containing exactly the character &quot;0&quot; -- such a
restriction would be inconsistent with other rules that need
compile-time-known values.  Thus, an expression like &quot;00&quot; or &quot;1 - 1&quot;
should be allowed.
</P>
<P>What does it mean that the restriction is &quot;checked prior to program
execution&quot;?  This could be interpreted to mean a legality check, or
could be interpreted to mean that a diagnostic message, such as a
warning message, must be given at compile time, but the program is still
legal, and may be executed.
</P>
<P>What exactly is being checked at compile time?  The only reasonable
interpretation would seem to be to check for the existence of an
object_declaration or allocator, where the type of the created object is
a task type, or is a composite type with some subcomponent type that is
a task type.  Thus, for example, a null array of tasks would fail this
check.
</P>
<P>The following possible interpretations exist:
</P>
<P><UL>1. If the implementation supports the Real-Time annex, the example program
is legal.  If the implementation supports the Safety and Security annex, the
example is illegal.  We reject this interpretation, because it
constitutes a contradiction between the two annexes.
</UL></P>
<P><UL>2. If the expression is statically zero, then the example is illegal,
if either annex is supported.  This is the interpretation chosen.
</UL></P>
<P><UL>3. If the expression is statically zero, then the example is legal.
However, if the implementation conforms to the Safety and Security annex, then it
must issue a warning message.  There is some precedent for
requiring warning messages -- see 2.8(13).  This seems like a
reasonable interpretation.  However, it seems better to simply
declare the program illegal -- a warning message doesn't have any
particular value here.
</UL></P>
<P><UL>4. Delete the requirement to check the restriction before run time.
We reject this, because it does not satisfy the needs of the Safety
and Security annex -- namely, to know at compile time whether the
program is wrong.
</UL></P>
<P>Similar arguments apply to Max_Asynchronous_Select_Nesting.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0077"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0077 -  Accept body not defined</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00111<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 D.11;  J.7.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The term &quot;accept body&quot; is used in D.11(18), J.7.1(16), and J.7.1(20). It is
not defined anywhere.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The phrase &quot;accept body&quot; should be replaced by other wording.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  D.11(18):   </FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
If a task becomes held while waiting in a <FONT FACE="Arial, Helvetica">selective_accept</FONT>,
and a entry call is issued to one of the open entries, the
corresponding accept body executes. When the rendezvous
completes, the active priority of the accepting task is
lowered to the held priority (unless it is still inheriting
from other sources), and the task does not execute until another Continue.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><UL><LI TYPE=DISC>
If a task becomes held while waiting in a <FONT FACE="Arial, Helvetica">selective_accept</FONT>,
and an entry call is issued to one of the open entries, the
corresponding <FONT FACE="Arial, Helvetica">accept_alternative</FONT> executes. When the rendezvous
completes, the active priority of the accepting task is
lowered to the held priority (unless it is still inheriting
from other sources), and the task does not execute until another Continue.</LI></UL></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  J.7.1(16):   </FONT></B></P>
<UL><P>Interrupt entry calls may be implemented by having the hardware execute
directly the appropriate accept body. Alternatively, the implementation is
allowed to provide an internal interrupt handler to simulate the effect of a
normal task calling the entry.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Interrupt entry calls may be implemented by having the hardware directly
execute the appropriate <FONT FACE="Arial, Helvetica">accept_statement</FONT>. Alternatively, the
implementation is allowed to provide an internal interrupt handler to
simulate the effect of a normal task calling the entry.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  J.7.1(20):   </FONT></B></P>
<P><UL><UL>
NOTES<BR>
1  Queued interrupts correspond to ordinary entry calls. Interrupts
that are lost if not immediately processed correspond to conditional
entry calls. It is a consequence of the priority rules that an accept
body executed in response to an interrupt can be executed with the
active priority at which the hardware generates the interrupt, taking
precedence over lower priority tasks, without a scheduling action.</UL></UL></P>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<P><UL><UL>
NOTES<BR>
1  Queued interrupts correspond to ordinary entry calls. Interrupts
that are lost if not immediately processed correspond to conditional
entry calls. It is a consequence of the priority rules that an
<FONT FACE="Arial, Helvetica">accept_statement</FONT> executed in response to an interrupt can be executed
with the active priority at which the hardware generates the interrupt, taking
precedence over lower priority tasks, without a scheduling action.</UL></UL></P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This was an editing error; &quot;accept body&quot; was defined in a draft of the standard.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0078"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0078 -  An RCI unit can be a library subprogram</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00048<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.2;  E.2.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The rules for pragma Shared_Passive (E.2.1(3)), pragma Remote_Types
(E.2.2(3)), and pragma Remote_Call_Interface (E.2.3(3)) seem to allow
them to apply to any library unit.  However, the definitions in E.2(4)
seem to imply that only packages and generic packages are allowed:
</P>
<P><UL>A library package or generic library
package is called a shared passive library unit if a Shared_Passive pragma
applies to it. A library package or generic
library package is called a remote types library unit if a Remote_Types
pragma applies to it. A library package or generic
library package is called a remote call interface if a Remote_Call_Interface
pragma applies to it. A normal library unit is one to
which no categorization pragma applies.
</UL></P>
<P>What is the intent?  Can a subprogram or generic subprogram be a shared
passive or remote types library unit?  (No.)  Can a subprogram or
generic subprogram be a remote call interface library unit?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A shared passive or remote types library unit must be a package or
generic package, not a subprogram or generic subprogram.  However, a
remote call interface library unit may be a package, generic package,
subprogram, or generic subprogram.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2(4):   </FONT></B></P>
<UL><P>A library package or generic library package is called a <I>shared passive</I>
library unit if a Shared_Passive pragma applies to it. A library package or
generic library package is called a <I>remote types</I> library unit if a
Remote_Types pragma applies to it. A library package or generic library package
is called a <I>remote call interface</I> if a Remote_Call_Interface pragma applies
to it. A <I>normal library unit</I> is one to which no categorization pragma
applies.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A library package or generic library package is called a <I>shared passive</I>
library unit if a Shared_Passive pragma applies to it. A library package or
generic library package is called a <I>remote types</I> library unit if a
Remote_Types pragma applies to it. A library unit is called a <I>remote call
interface</I> if a Remote_Call_Interface pragma applies to
it. A <I>normal library unit</I> is one to which no categorization pragma
applies.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(7):   </FONT></B></P>
<UL><P>A <I>remote call interface (RCI)</I> is a library unit to which the pragma
Remote_Call_Interface applies. A subprogram declared in the visible part of
such a library unit is called a <I>remote subprogram</I>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>A <I>remote call interface (RCI)</I> is a library unit to which the pragma
Remote_Call_Interface applies. A subprogram declared in the visible part of
such a library unit, or declared by such a library unit, is called a
<I>remote subprogram</I>.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(9):   </FONT></B></P>
<UL><P>In addition, the following restrictions apply to the visible part of an
RCI library unit:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>In addition, the following restrictions apply to an RCI library unit:
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(10):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain the declaration of a variable;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
its visible part shall not contain the declaration of a variable;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(11):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain the declaration of a limited type;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
its visible part shall not contain the declaration of a limited type;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(12):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain a nested <FONT FACE="Arial, Helvetica">generic_declaration</FONT>;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
its visible part shall not contain a nested <FONT FACE="Arial, Helvetica">generic_declaration</FONT>;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(13):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain the declaration of a subprogram to which a
pragma Inline applies;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not be, nor shall its visible part contain, the declaration
of a subprogram to which a pragma Inline applies;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(14):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain a subprogram (or access-to-subprogram)
declaration whose profile has an access parameter, or a formal
parameter of a limited type unless that limited type has
user-specified Read and Write attributes;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not be, nor shall its visible part contain, a
subprogram (or access-to-subprogram) declaration whose profile
has an access parameter, or a formal parameter of a limited type
unless that limited type has user-specified Read and Write attributes;</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.3(19):   </FONT></B></P>
<UL><P>If a pragma All_Calls_Remote applies to a given RCI library package,
then the implementation shall route any call to a subprogram of the RCI
package from outside the declarative region of the package through the
Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms
from within the declarative region of the package are defined to be local and
shall not go through the PCS.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>If a pragma All_Calls_Remote applies to a given RCI library unit,
then the implementation shall route any call to a subprogram
of the RCI unit from outside the declarative region of the unit
through the Partition Communication Subsystem (PCS); see E.5.
Calls to such subprograms from within the declarative region of
the unit are defined to be local and shall not go through the PCS.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The wording is ambiguous, and the intent is unclear.  Clearly, shared
passive subprograms and remote types subprograms make no sense.
However, RCI subprograms make sense.  We have two choices:
</P>
<P>Option 1: A shared passive, remote types, or remote call interface
library unit must be a package or generic package, not a subprogram or
generic subprogram.
</P>
<P>Option 2 (as in the summary above): A shared passive or remote types
library unit must be a package or generic package, not a subprogram or
generic subprogram.  However, a remote call interface library unit may
be a package, generic package, subprogram, or generic subprogram.  A
main subprogram may be an RCI unit.
</P>
<P>The argument for Option 1 is that RCI subprograms are not particularly
important, the original designers apparently intended to allow only
packages, and the wording changes are easier if this choice is chosen.
</P>
<P>The argument for Option 2 is that RCI subprograms make sense (given that
library subprograms are allowed in the first place), and it would seem
like an ugly and arbitrary restriction to disallow them.
</P>
<P>We choose Option 2.
</P>
<P>Note that, given the above wording changes, 10.2(29) without changes
implies that main subprograms that are RCI subprograms must be
supported.  We see no implementation difficulty in that.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0079"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0079 -  What is the meaning of "same representation" in all partitions?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00208<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The implementation requirement E.2(13) says:
</P>
<P><UL>For a given library-level type declared in a preelaborated library
unit or in the declaration of a remote types or remote call
interface library unit, the implementation shall choose the same
representation for the type upon each elaboration of the type's
declaration for different partitions of the same program.
</UL></P>
<P>This seems overly restrictive. It means that the standard
supports heterogeneous distributed systems only if the implementation
manages to use the same representation for a type on all nodes.
Is this intended? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>E.2(13) requires the &quot;same representation&quot; in all partitions.
This requirement prevents heterogeneous distributed systems, and is not needed,
so it is deleted.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Delete  E.2(13):  </FONT></B></P>
<UL><P>For a given library-level type declared in a preelaborated library unit
or in the declaration of a remote types or remote call interface library
unit, the implementation shall choose the same representation for the type
upon each elaboration of the type's declaration for different partitions of
the same program.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The requirement for the same representation for types in shareable library
packages is over-specification. What is required is that the types have
similar semantics and have consistent values when remotely accessed.
While requiring the same representation insures that the requirement is met,
it prevents many possible heterogeneous systems. For instance, the byte
order of integer types may be different on different processors, but this
has no effect on the semantics of the types.
</P>
<P>If an implementation uses a representation independent format for its
communication between partitions, heterogeneous distributed systems on
processors with differing numeric formats can be supported. (Note that the
storage element stream for a scalar type is implementation-defined.) Such an
implementation could correctly support all of the semantics of Annex E.
</P>
<P>Such heterogeneous systems have been used in avionics to insure that answers
calculated are independent of implementation and processor errors. This is
done by calculating answers on several different processors (each with its
own executable code), and comparing them. Ada should support the construction
of such systems with each processor running one or more active partitions.
</P>
<P>Furthermore, there seems to be no reason to require the rule even for
homogeneous systems. The rule essentially says that the easiest implementation
is required. If an Ada implementation has a reason to go through the extra
work to support multiple representations, there seems to be no reason for
the standard to get in its way.
</P>
<P>If an implementation does support different representations in different
active partitions, we believe it is best to leave the exact semantics to the
implementation. We expect that implementations will do what is necessary to
insure that the semantics of types with different representations is similar
and meaningful in each partition.
</P>
<P>Therefore, the rule requiring the same representation in each partition is
not needed, and is deleted.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0080"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0080 -  Access types declared in shared passive generic packages</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00003<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.2.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>E.2.1(7) states that a shared passive library unit &quot;shall not contain a
library-level declaration of an access type that designates a class-wide
type, task type, or protected type with entry_declarations; if the
shared passive library unit is generic, it shall not contain a
declaration for such an access type unless the declaration is nested
within a body other than a package_body.&quot;
</P>
<P>This allows such an access type in a block_statement in the
sequence_of_statements of the body of a package, but not of a generic
package (since a block_statement is not a &quot;body other than a
package_body&quot;).  Is this intended?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A declaration of an access type that designates a class-wide type, task
type, or protected type with entry_declarations is allowed within a
block_statement in the sequence_of_statements of a generic shared
passive package.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.1(7):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain a library-level declaration of an access
type that designates a class-wide type, task type, or protected
type with <FONT FACE="Arial, Helvetica">entry_declaration</FONT>s; if the shared passive library unit
is generic, it shall not contain a declaration for such an access
type unless the declaration is nested within a body other than a
<FONT FACE="Arial, Helvetica">package_body</FONT>.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
it shall not contain a library-level declaration of an access
type that designates a class-wide type, task type, or protected
type with <FONT FACE="Arial, Helvetica">entry_declaration</FONT>s.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent of the part of E.2.1(7) after the semicolon is to forbid
certain access types in a generic shared passive package, unless the
access type is declared within a master.  3.10.2(20) says:
</P>
<P><UL>For determining whether one level is statically deeper than
another when within a generic package body, the generic package
is presumed to be instantiated at the same level as where it was
declared; run-time checks are needed in the case of more deeply
nested instantiations.
</UL></P>
<P>This implies that the part of E.2.1(7) after the semicolon is redundant,
except in the case of block_statements.  The block_statement case was
not intended to be forbidden (and is not forbidden in the non-generic
case).  Thus, these words should be deleted.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0081"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0081 -  Conversions to types derived from remote access types</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00004<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.2.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>NOTE 3.4(31) says, &quot;If the parent type is an access type, then the
parent and the derived type share the same storage pool...&quot;.  E.2.2(17)
says:
</P>
<P><UL>The Storage_Pool and Storage_Size attributes are not defined for
remote access-to-class-wide types; the expected type for an
allocator shall not be a remote access-to-class-wide type; a
remote access-to-class-wide type shall not be an actual parameter
for a generic formal access type;
</UL></P>
<P>This seems to imply that a remote access type has no storage pool, which
is confirmed by AARM E.2.2(17.a):
</P>
<P><UL>Reason:  All three of these restrictions are because there is no
storage pool associated with a remote access-to-class-wide type.
</UL></P>
<P>However, E.2.2(17) allows allocators for types derived from remote
access types.  How can an allocator work for a type that has no storage
pool?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Notwithstanding the rule in 3.10(7), a remote access type (unlike other
access types) has no associated storage pool.  If a type is derived from
a remote access type, then the derived type is also a remote access
type.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.2(9):   </FONT></B></P>
<UL><P>An access type declared in the visible part of a remote types or remote
call interface library unit is called a <I>remote access type</I>. Such a type
shall be either an access-to-subprogram type or a general access type that
designates a class-wide limited private type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An access type declared in the visible part of a remote types or remote
call interface library unit is called a <I>remote access type</I>. Such a type
shall be either an access-to-subprogram type or a general access type that
designates a class-wide limited private type. A type that is derived from
a remote access type is also a remote access type.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Notwithstanding the rule in 3.10(7), a remote access type (unlike other
access types) has no associated storage pool.  If a type is derived from
a remote access type, then the derived type is also a remote access
type, and hence also has no associated storage pool.
Thus, type conversions are allowed between such types (see E.2.2(11,15)).
The restrictions in E.2.2(10-17) apply to types derived from remote
access types.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Normally, a derived access type has the same storage pool as its parent.
See 8652/0012 (AI-00062), which confirms NOTE 3.4(31).  However, the intent of
E.2.2(17) is that a remote access type has no storage pool.  Therefore,
a type derived from a remote access type cannot have a storage pool,
either.  Querying 'Storage_Pool and 'Storage_Size should be illegal by
E.2.2(17).  Similarly, allocators should be illegal.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0082"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0082 -  Definition of remote access type</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00164<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.2.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>An interpretation of E.2.2(9) would deny object-oriented programming
methodology to distributed Ada programmers by not permitting a
remote-access-to-class-wide (RACW) type to designate a class-wide private
extension of limited private type. If this interpretation holds then the
following example is illegal:
</P>
<PRE><TT><UL><B>package</B> RT <B>is</B>
   <B>pragma</B> Remote_Types;
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> Root_Object <B>is</B> <B>abstract</B> <B>tagged</B> <B>limited</B> <B>private</B>;
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> New_Object <B>is</B> <B>new</B> Root_Object <B>with</B> <B>private</B>;
</UL></TT></PRE>
<PRE><TT><UL>   -- Primitive dispatched procedures of New_Object.
   <B>procedure</B> Operation_1 (Obj : <B>access</B> New_Object; Z : Integer);
</UL></TT></PRE>
<PRE><TT><UL><B>private</B>
   <B>type</B> Root_Object <B>is</B> <B>abstract</B> <B>tagged</B> <B>limited</B> <B>null</B> <B>record</B>;
   <B>type</B> New_Object <B>is</B> <B>new</B> Root_Object <B>with</B> <B>null</B> <B>record</B>;
<B>end</B> RT;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> RT;
<B>package</B> RCI <B>is</B>
    <B>pragma</B> Remote_Call_Interface;
</UL></TT></PRE>
<PRE><TT><UL>    <B>type</B> New_Access <B>is</B> <B>access</B> <B>all</B> RT.New_Object'Class;
    --   ^^^^^^^^^^
    --     illegal
</UL></TT></PRE>
<PRE><TT><UL>    <B>procedure</B> Register (New_Obj : New_Access);
<B>end</B>;
</UL></TT></PRE>
<P>Also, while limitedness of the target type is clearly needed, there seems
to be no reason why the target type needs to be private.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>E.2.2(9) is interpreted to permit a remote access-to-class-wide
type to designate a class-wide private extension of a limited
private type.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.2(9):   </FONT></B></P>
<UL><P>An access type declared in the visible part of a remote types or remote
call interface library unit is called a <I>remote access type</I>. Such a type
shall be either an access-to-subprogram type or a general access type that
designates a class-wide limited private type.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An access type declared in the visible part of a remote types or remote
call interface library unit is called a <I>remote access type</I>. Such a type
shall be:
</P></UL>
<UL><UL><LI TYPE=DISC>
an access-to-subprogram type, or</LI></UL></UL>
<UL><UL><LI TYPE=DISC>
a general access type that designates a class-wide limited private type
or a class-wide private type extension all of whose ancestors are either private
type extensions or limited private types.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>There were two issues raised:
</P>
<P><UL>application of RACW to private extension of limited private type;
</UL></P>
<P><UL>removal of restriction on RACW to private types.
</UL></P>
<P>Regarding the first issue, the intent of E.2.2(9) is not to exclude
private extensions. The conclusion that E.2.2(9) denies distributed
object programming seems unwarranted given that typically the
designated type is most naturally extended in the body of a package
where the distributed/remote object is declared.
</P>
<P>Regarding the second issue, if E.2.2(9) is relaxed to allow the type to be
completed in the visible part of the package this would provide additional
capability only to those objects that are to be accessed locally. Thus,
there is no significant gain in a distributed application. The requirement
that the designated type of the remote access-to-class-wide type be limited
private is consistent with that placed upon a file type since in each case
they both provide a handle to some external object.
</P>
<P>Retaining the restriction that this paragraph apply to only private
types (and their extensions) ensures the least surprise to developers
when non-distributed software modules are subsequently inserted into a
distributed environment.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0083"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0083 -  {User-defined} Read and Write attributes</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00047<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.2.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>E.2.2(14) says, &quot;... the types of all the noncontrolling formal
parameters shall have Read and Write attributes.&quot;
</P>
<P>By 13.13.2(2), this is vacuously true.  Do you mean <I>user-specified</I>
Read and Write attributes, as suggested by the note in E.2.2(18)?
(That would be a strange requirement for, say, a parameter of type
Integer, but the obvious alternative interpretation also seems strange.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Consider a remote access-to-classwide type, whose corresponding specific
type is T, and a primitive subprogram P of T.  For each non-controlling
parameter of P, if its type is limited, it must have user-defined 'Read
and 'Write operations.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.2.2(14):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
The primitive subprograms of the corresponding specific limited private
type shall only have access parameters if they are controlling formal
parameters; the types of all the non-controlling formal parameters shall
have Read and Write attributes.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
The primitive subprograms of the corresponding specific limited private
type shall only have access parameters if they are controlling formal
parameters; each non-controlling formal parameter shall have either a
nonlimited type or a type with Read and Write attributes specified via an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>;</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent of E.2.2(14) is to require that every non-controlling
parameter have 'Read and 'Write operations that can be called.  Although
'Read and 'Write always <I>exist</I> by 13.13.2(2), it is illegal to call
them for limited types, unless they are user specified, by 13.13.2(36).
(The reason for this circumlocution was to avoid a generic contract
model problem.)
</P>
<P>To see the reason for the rule, consider the following example:
</P>
<PRE><TT><UL><B>package</B> Pure_Pkg <B>is</B>
   <B>type</B> Lim <B>is</B> <B>limited</B>
      <B>record</B>
         ...
      <B>end</B> <B>record</B>;
   <B>for</B> Lim'Read <B>use</B> ...;
   <B>for</B> Lim'Write <B>use</B> ...;
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> T <B>is</B> <B>abstract</B> <B>tagged</B> <B>limited</B> <B>private</B>;
   <B>procedure</B> P(Controlling_Param: <B>access</B> T;
               Noncontrolling_Param: Lim) <B>is</B> <B>abstract</B>;
<B>private</B>
   ...
<B>end</B> Pure_Pkg;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Pure_Pkg; <B>use</B> Pure_Pkg;
<B>package</B> RCI <B>is</B>
   <B>pragma</B> Remote_Call_Interface;
</UL></TT></PRE>
<PRE><TT><UL>   <B>type</B> Remote_Access_To_Classwide <B>is</B> <B>access</B> <B>all</B> T'Class;
<B>end</B> RCI;
</UL></TT></PRE>
<P>Now we declare an object of the remote access-to-classwide type:
</P>
<PRE><TT><UL>X: Remote_Access_To_Classwide := ...;
</UL></TT></PRE>
<P>X might point to an object in some other partition.
</P>
<P>Now we write a dispatching call:
</P>
<PRE><TT><UL>L: Lim;
...
P(X, L);
</UL></TT></PRE>
<P>This will do a remote call to whatever partition contains the object
designated by X.  We need to transfer the value of L to that partition,
which would be impossible if Lim did not have user-defined Read and
Write attributes.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0084"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0084 -  Version and Body_Version attributes</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00104<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Two questions:
</P>
<P>E.3(4) says:
</P>
<P><UL>P'Body_Version
</UL></P>
<P><UL><UL>Yields a value of the predefined type String that identifies
the version of the compilation unit that contains the body
(but not any subunits) of the program unit.
</UL></UL></P>
<P>What if the program unit has no body?
</P>
<P>E.3(5) says:
</P>
<P><UL>The version of a compilation unit changes whenever the version changes
for any compilation unit on which it depends semantically.  The version also
changes whenever the compilation unit itself changes in a semantically
significant way.  It is implementation defined whether there are other events
(such as recompilation) that result in the version of a compilation unit
changing.
</UL></P>
<P>First of all, it is not clear what &quot;semantically significant&quot; means.
Second of all, the &quot;implementation defined&quot; part seems to leave a huge
loophole; an implementation could change the version on every clock tick
(at run time), which would mean the Version and Body_Version attributes
would return a different value every time, which would make them
useless.  What is the intent?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If P is not a library unit, and P has no completion, then P'Body_Version
returns the Body_Version of the innermost program unit enclosing the
declaration of P.  If P is a library unit, and P has no completion
(which can be detected at compile time), then P'Body_Version returns a
value that is different from Body_Version of any version of P that has a
completion.
</P>
<P>E.3(5) is replaced with:
</P>
<P>The version of a compilation unit changes whenever the compilation unit
changes in a semantically significant way.  This International Standard
does not define the exact meaning of &quot;semantically significant&quot;.  It is
also unspecified whether there are other events (such as recompilation)
that result in the version of a compilation unit changing.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.3(5):   </FONT></B></P>
<UL><P>The <I>version</I> of a compilation unit changes whenever the version changes
for any compilation unit on which it depends semantically. The version also
changes whenever the compilation unit itself changes in a semantically
significant way. It is implementation defined whether there are other events
(such as recompilation) that result in the version of a compilation unit
changing.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The <I>version</I> of a compilation unit changes whenever the compilation unit
changes in a semantically significant way. This International Standard
does not define the exact meaning of &quot;semantically significant&quot;. It is
also unspecified whether there are other events (such as recompilation)
that result in the version of a compilation unit changing.
</P></UL>
<UL><P>If P is not a library unit, and P has no completion, then P'Body_Version
returns the Body_Version of the innermost program unit enclosing the
declaration of P. If P is a library unit, and P has no completion,
then P'Body_Version returns a value that is different from Body_Version
of any version of P that has a completion.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>It should not be an error to query P'Body_Version when P has no body,
because:
</P>
<P><UL>1. The purpose of P'Body_Version is to distinguish different
implementations of P.  If P has a body, that is a different
implementation of P than if P does not have a body.
P'Body_Version should return a different value in those two
cases, not give an error.  The client cares whether the
implementation of P has changed; the client should not have to
know whether or not that implementation involves a body.
</UL></P>
<P><UL>2. The &quot;error&quot; is not detectable at compile time, in general.  In
particular, if P is not a library unit, one cannot tell from the
declaration of P whether or not it has a body.
</UL></P>
<P>The summary uses the term &quot;completion&quot; to account for the fact that
there might be a pragma Import instead of a body.
</P>
<P>As to the second question, we choose to leave &quot;semantically significant&quot;
vague, and trust implementations to do something sensible.  The version
should not change at the drop of a hat; in any given implementation,
there should at least be some way of ensuring that execution of
identical source code produces an identical version at run time.
Some sensible implementations are:
</P>
<P><UL>- The &quot;traditional&quot; (Ada 83) program library model: It would make
sense for the version to be a time stamp representing the time of
compilation.  If the programmer recompiles a compilation unit, it
will get a new version.  The mechanism for ensuring identical
versions is, &quot;Don't recompile it&quot;.
</UL></P>
<P><UL>- A &quot;source-based&quot; model: The version is a combination of the time
stamp of the source of the compilation unit itself, plus all
compilation units upon which it depends semantically.  If the
compiler can guarantee that the same source always produces the
same object code, which is usual, then the version could change if
and only if the user edits the source files (whether or not any
changes were actually made).  The mechanism for ensuring identical
versions is, &quot;Don't edit the source files&quot;.
</UL></P>
<P><UL>- An optimization of the source-based model: The version is a &quot;hash
value&quot; calculated from the source code of the compilation unit
itself, plus all compilation units upon which it depends
semantically.  Comments are deleted before calculating the hash
value.  The mechanism for ensuring identical versions is, &quot;Don't
edit the source files, except to modify comments.&quot;
</UL></P>
<P><UL>- A different optimization: The last 20 versions of every file are
remembered by the implementation.  If the current version is
identical to one of the remembered ones, then it gets the same
version.  Otherwise, it gets a new version.
</UL></P>
<P>We don't want to require that identical source code always produces
identical versions at run time.  However, an implementation should
provide <I>some</I> way of producing identical versions at run time when the
source code hasn't changed.  All of the above-mentioned possible
implementations have this property.  One can imagine much more
sophisticated mechanisms, and we don't want to forbid them.
</P>
<P>In any case, it seems reasonable that if the object code changes, the
version should change.  We state this &quot;only&quot; as advice, because the
International Standard has no formal concept of object code.  In particular,
there is no standard way of knowing which pieces of object code belong to
which compilation units.
</P>
<P>The intent is that if the user does something semantically neutral, like
adding a comment, then an implementation should be <I>allowed</I> to keep the
version the same.  In order to facilitate such &quot;smart recompilation&quot;
strategies, we remove the phrase &quot;implementation defined&quot; from E.3(5),
so that implementations need not document the exact cases when the
version changes.
</P>
<P>Note that we remove the wording, &quot;The version of a compilation unit
changes whenever the version changes for any compilation unit on which
it depends semantically.&quot; from E.3(5), because a compiler might be able
to prove that whatever change was made to the compilation unit on which
it depends semantically is irrelevant.
</P>
<P>In summary, in our view, the version of a compilation unit should change
when its generated code changes.  The version of a compilation unit
should change when the version changes for a compilation unit upon which
it depends semantically, if the change has a semantically significant
effect on the first compilation unit.  There may be other situations
that also cause the version to change, but the implementation should
provide a way to ensure that the version does not change if the
compilation unit and the compilation units upon which it depends
semantically do not change.
</P>
<P>Note that if X is a renaming declaration (not a renaming-as-body), then
X'Version and X'Body_Version refer to the versions of the renamed
entities.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0085"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0085 -  Returning remote class-wide values</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00215<BR>
Report Qualifier -- Omission<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The rule of E.4(18) requires a check for the actual parameter of a remote
subprogram call with a formal parameter of a class-wide type. This check
is to prevent the passage of objects whose type is not a &quot;communicable&quot; type.
However, no check is required for a function returning a class-wide object.
Therefore, a function can return an object that is not of a &quot;communicable&quot;
type. Was this intended? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A check is made on the result of a remote function call that returns a
class-wide type that it does not violate the conditions described in section
E.4(18).
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  E.4(18):   </FONT></B></P>
<UL><P>In a remote subprogram call with a formal parameter of a class-wide
type, a check is made that the tag of the actual parameter identifies a
tagged type declared in a declared-pure or shared passive library unit, or in
the visible part of a remote types or remote call interface library unit.
Program_Error is raised if this check fails.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>In a remote subprogram call with a formal parameter of a class-wide
type, a check is made that the tag of the actual parameter identifies a
tagged type declared in a declared-pure or shared passive library unit, or in
the visible part of a remote types or remote call interface library unit.
Program_Error is raised if this check fails. In a remote function call which
returns a class-wide type, the same check is made on the function result.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The purpose of the rule E.4(18) is to prevent the passage of objects which
have types that are not &quot;communicable&quot; types.  (That is, types which are not
known to the other partitions.) Normally this is enforced at compile-time,
but with class-wide types, the check needs to be a run-time check.
</P>
<P>The rule would not be helpful if there was a way to pass objects of types
that are not &quot;communicable&quot;. However, exactly that can be done by returning
such an object from a function. Clearly, a check needs to be made on such
results as well.
</P>
<P>Note that the return statement in the function itself cannot know whether
or not it was called remotely. Therefore, the check must be made by the
remote function call return code when the object is marshalled to be
returned to the caller.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0086"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0086 -  Shared variables in Shared_Passive?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00159<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.4</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>There is no task rendezvous between two partitions, and protected
entries are disallowed in Shared_Passive packages, so how can two
actions of reading/updating variables declared in a Shared_Passive
package performed on two different partitions be sequential as
defined by 9.10(11)?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>For the purposes of the shared variables rules in 9.10, with respect to
shared variables in shared passive partitions, a synchronous remote
procedure call is considered to be part of the execution of the calling
task.
</P>
<P>For an asynchronous RPC, the call signals the start of the remote body,
but the body then proceeds in parallel, and thus does not signal the
next action of the calling task.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  E.4(20):   </FONT></B></P>
<UL><P>The implementation of remote subprogram calls shall conform to the PCS
interface as defined by the specification of the language-defined package
System.RPC (see E.5). The calling stub shall use the Do_RPC procedure unless
the remote procedure call is asynchronous in which case Do_APC shall be used.
On the receiving side, the corresponding receiving stub shall be invoked by
the RPC-receiver.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraph:</FONT></B></P>
<UL><P>With respect to shared variables in shared passive library units, the
execution of the corresponding subprogram body of a synchronous remote
procedure call is considered to be part of the execution of the calling task.
The execution of the corresponding subprogram body of an asynchronous remote
procedure call proceeds in parallel with the calling task and does not signal
the next action of the calling task (see 9.10).
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>9.10 says:
</P>
<P><UL>(2)  Separate tasks normally proceed independently and concurrently with one
another.  However, task interactions can be used to synchronize the actions
of two or more tasks to allow, for example, meaningful communication by the
direct updating and reading of variables shared between the tasks.  The
actions of two different tasks are synchronized in this sense when an action
of one task signals an action of the other task; an action A1 is defined to
signal an action A2 under the following circumstances:
</UL></P>
<P><UL><UL>(3) If A1 and A2 are part of the execution of the same task, and the
language rules require A1 to be performed before A2;
</UL></UL></P>
<P><UL><UL>...
</UL></UL></P>
<P><UL><UL>(7) If A1 is the action of issuing an entry call, and A2 is part of
the corresponding execution of the appropriate entry_body or
accept_statement.
</UL></UL></P>
<P><UL><UL>(8) If A1 is part of the execution of an accept_statement or
entry_body, and A2 is the action of returning from the corresponding
entry call;
</UL></UL></P>
<P><UL><UL>(9) If A1 is part of the execution of a protected procedure body or
entry_body for a given protected object, and A2 is part of a
later execution of an entry_body for the same protected object;
</UL></UL></P>
<P><UL><UL>(10)If A1 signals some action that in turn signals A2.
</UL></UL></P>
<P><UL>Erroneous Execution
</UL></P>
<P><UL>(11) Given an action of assigning to an object, and an action of reading or
updating a part of the same object (or of a neighboring object if the two are
not independently addressable), then the execution of the actions is
erroneous unless the actions are sequential.  Two actions are sequential if
one of the following is true:
</UL></P>
<P><UL><UL>(12) One action signals the other;
</UL></UL></P>
<P><UL><UL>(13) Both actions occur as part of the execution of the same task;
</UL></UL></P>
<P><UL><UL>(14) Both actions occur as part of protected actions on the same
protected object, and at most one of the actions is part of a
call on a protected function of the protected object.
</UL></UL></P>
<P>A remote procedure call is a procedure call, so 9.10(3) implies that
RPC's are signaling, so long as we view the call as taking place within
the execution of a single task.
</P>
<P>The only problem is that asynchronous RPC's are weird; the caller
proceeds without awaiting return of the call.  Thus, we need a
special-case rule for that case.
</P>
<P>As an example, suppose a task in one partition writes upon a shared
variable in a shared passive partition.  It may then do an RPC to notify
other partitions that it has done writing.  The other partitions may
then safely read from that shared variable.
</P>
<P>As a special case, consider a partition that initializes such a shared
variable during that partition's elaboration.  E.4(14) says:
</P>
<P><UL>If a remote subprogram call is received by a called partition before
the partition has completed its elaboration, the call is kept pending
until the called partition completes its elaboration (unless the call
is cancelled by the calling partition prior to that).
</UL></P>
<P>So other partitions may assume that the shared variable has been
initialized, so long as they first do an RPC (that does not raise
Communication_Error) to the initializing partition.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0087"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0087 -  The PCS may be defined by the user</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00082<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 E.5</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>A(4) says:
</P>
<P><UL>The implementation may restrict the replacement of language-defined
compilation units. The implementation may restrict children of
language-defined library units (other than Standard).
</UL></P>
<P>Is this intended to apply to the body of System.RPC, or its children?
(No.)
</P>
<P>May an implementation require that a particular version of System.RPC be
used?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An implementation that conforms to Annex E, and that supports pragma
Remote_Call_Interface (which is not required -- see E.2.3(20)) must
allow the user to compile a body for System.RPC, and to compile children
of System.RPC.
</P>
<P>Such an implementation must implement remote subprogram calls using
(only) the facilities of System.RPC; the generated code is not allowed
to depend on special properties of one particular implementation of
System.RPC, but must work for any correct implementation of System.RPC.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Insert after  E.5(24):   </FONT></B></P>
<UL><P>The implementation of the RPC-receiver shall be reentrant, thereby
allowing concurrent calls on it from the PCS to service concurrent remote
subprogram calls into the partition.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">the new paragraphs:</FONT></B></P>
<UL><P>An implementation shall not restrict the replacement of the body of System.RPC.
An implementation shall not restrict children of System.RPC. The related
implementation permissions in the introduction to Annex A do not apply.
</P></UL>
<UL><P>If the implementation of System.RPC is provided by the user, an implementation
shall support remote subprogram calls as specified.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is that the PCS be implemented by the user, or by a third
party vendor -- it need not be implemented by the Ada compiler vendor.
Hence, it is important that the user be able to provide a body, and
child units, for System.RPC.  This requires:
</P>
<P><UL>(1) The Ada compiler vendor must allow users to compile the body and
children of System.RPC, despite A(4).
</UL></P>
<P><UL>(2) The Ada compiler must generate code that will work properly
with any correct implementation of the PCS; thus, the generated
code must use the defined interface, and only that interface,
and not depend on details of a particular PCS implementation.
</UL></P>
<P>Thus, it would be correct for a validation test to provide a PCS
implementation, and require the implementation to use that PCS in tests.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0088"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0088 -  Picture string grammar or composition rules need tightening</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00153<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 F.3.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The String &quot;++++&gt;&quot; and like Strings with '&gt;' unmatched by any '&lt;' appear to
be valid picture strings based on the following production sequence (from
F.3.1):
</P>
<P><UL>picture string   ::= ... | non_currency_picture_string
</UL></P>
<P><UL>non_currency_picture_string ::= all_sign_number | ...
</UL></P>
<P><UL>all_sign_number  ::= all_sign_fore [...] [&gt;]
</UL></P>
<P><UL>all_sign_fore    ::= sign_char {...} sign_char {sign_char | ...}
</UL></P>
<P><UL>sign_char        ::= + | - | &lt;
</UL></P>
<P>Is the picture string &quot;++++&gt;&quot; well formed? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Picture strings such as &quot;++++&gt;&quot; are not well formed.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  F.3.1(43):   </FONT></B></P>
<UL><UL><LI TYPE=DISC>
If a picture String has '+' or '-' as <FONT FACE="Arial, Helvetica">fixed_LHS_sign</FONT>, in a
<FONT FACE="Arial, Helvetica">floating_LHS_sign</FONT>, or in an <FONT FACE="Arial, Helvetica">all_sign_number</FONT>, then it has no
<FONT FACE="Arial, Helvetica">RHS_sign</FONT>.</LI></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><LI TYPE=DISC>
If a picture String has '+' or '-' as <FONT FACE="Arial, Helvetica">fixed_LHS_sign</FONT>, in a
<FONT FACE="Arial, Helvetica">floating_LHS_sign</FONT>, or in an <FONT FACE="Arial, Helvetica">all_sign_number</FONT>, then it has no
<FONT FACE="Arial, Helvetica">RHS_sign</FONT> or '&gt;' character.</LI></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A '&gt;' character can only appear in an all_sign_number if it contains '&lt;'
characters.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The problem is that the production for all_sign_number does not use the
RHS_sign production, it contains the literal '&gt;'. The picture string grammar
and composition constraints were folded into as few words as possible, too
few in this case. Some of the composition constraints could have been included
in a context-free grammar but at the expense of making it much longer, and
more difficult to read.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0089"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0089 -  Incorrect picture string example</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00070<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 F.3.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The picture example in F.3.2(74) is invalid, since a floating currency symbol
is not allowed in the same picture string as a zero suppression symbol.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The example in F.3.2(74) has been corrected.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  F.3.2(74):   </FONT></B></P>
<UL><UL><PRE><TT>123456.78     Picture:  &quot;-$$$**_***_**9.99&quot;
              Result:   &quot;bbb$***123,456.78&quot;
                       &quot;bbbFF***123.456,78&quot; (currency = &quot;FF&quot;,
                                             separator = '.',
                                             radix mark = ',')</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT>123456.78     Picture:    &quot;-$**_***_**9.99&quot;
              Result:     &quot;b$***123,456.78&quot;
                         &quot;bFF***123.456,78&quot; (currency = &quot;FF&quot;,
                                             separator = '.',
                                             radix mark = ',')</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The example was incorrect.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0090"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0090 -  Should "pragma" be in boldface?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00028<BR>
Report Qualifier -- Presentation<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 G.1.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Should &quot;pragma&quot; be in boldface? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>&quot;pragma&quot; should be in boldface.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  G.1.1(2):   </FONT></B></P>
<UL><UL><PRE><TT><B>generic</B>
   <B>type</B> Real <B>is digits</B> &lt;&gt;;
<B>package</B> Ada.Numerics.Generic_Complex_Types <B>is</B>
   pragma Pure(Generic_Complex_Types);</TT></PRE></UL></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><UL><PRE><TT><B>generic</B>
   <B>type</B> Real <B>is digits</B> &lt;&gt;;
<B>package</B> Ada.Numerics.Generic_Complex_Types <B>is</B>
   <B>pragma</B> Pure(Generic_Complex_Types);</TT></PRE></UL></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>This was an editing error.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0091"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0091 -  Polar implementation of complex exponentiation for negative exponents</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00156<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 G.1.1</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>G.1.1(55) gives the following method for doing complex exponentiation
in polar form:
</P>
<P><UL>... exponentiating the modulus by the given exponent; multiplying
the argument by the given exponent, when the exponent is positive,
or dividing the argument by the absolute value of the given
exponent, when the exponent is negative; ...
</UL></P>
<P>The special case for the determining the argument of the result when the
exponent is negative is incorrect.  The method given for positive
exponents should be applied for all exponents, including interestingly
enough, zero exponents.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The second sentence of G.1.1(55) should read:
</P>
<P><UL>Implementations are also permitted to obtain the result of
exponentiation of a complex operand, but not of a pure-imaginary
operand, by converting the left operand to a polar representation,
exponentiating the modulus by the given exponent, multiplying the
argument by the given exponent, and reconverting to a Cartesian
representation.
</UL></P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  G.1.1(55):   </FONT></B></P>
<UL><P>Implementations may obtain the result of exponentiation of a complex or
pure-imaginary operand by repeated complex multiplication, with arbitrary
association of the factors and with a possible final complex reciprocation
(when the exponent is negative). Implementations are also permitted to
obtain the result of exponentiation of a complex operand, but not of a
pure-imaginary operand, by converting the left operand to a polar
representation; exponentiating the modulus by the given exponent; multiplying
the argument by the given exponent, when the exponent is positive, or
dividing the argument by the absolute value of the given exponent, when the
exponent is negative; and reconverting to a cartesian representation.
Because of this implementation freedom, no accuracy requirement is imposed on
complex exponentiation (except for the prescribed results given above, which
apply regardless of the implementation method chosen).
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>Implementations may obtain the result of exponentiation of a complex or
pure-imaginary operand by repeated complex multiplication, with arbitrary
association of the factors and with a possible final complex reciprocation
(when the exponent is negative). Implementations are also permitted to
obtain the result of exponentiation of a complex operand, but not of a
pure-imaginary operand, by converting the left operand to a polar
representation, exponentiating the modulus by the given exponent,
multiplying the argument by the given exponent, and reconverting to a
cartesian representation. Because of this implementation freedom, no
accuracy requirement is imposed on complex exponentiation (except for the
prescribed results given above, which apply regardless of the
implementation method chosen).
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>Here is a proof by example that the given method is incorrect:
</P>
<P>Assume that the method described in the standard is correct.
</P>
<P>Let a complex number X = i and let an integer n = -1.
</P>
<P>Then X**n = 1/i = -i, argument(X) = pi/2 and n is negative.
</P>
<P>So, according to G.1.1(55), argument(X**n) = (pi/2)/|-1| = pi/2,
but argument(X**n) = argument(-i) = -pi/2.
</P>
<P>Obviously, pi/2 is not equal to -pi/2 (even as an angle); i.e. a
contradiction has been found.
No zero-valued complex numbers were involved (they can mess things up).
The only dubious assumption made was that the method described in G.1.1(55) was
correct. So, it must not be.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0092"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0092 -  Does Complex_IO handle extended real literals?</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00029<BR>
Report Qualifier -- Error<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 G.1.3</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>G.1.3(12) says that Complex_IO.Get reads a pair of optionally signed
real literals.  This is inconsistent with A.10.9(13-18), which allow
certain extended forms of real literals in Float_IO.Get.  Should
Complex_IO.Get allow the same extended forms?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The syntax of real literals read by Ada.Text_IO.Complex_IO.Get is the
same as that of Ada.Text_IO.Float_IO.Get.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  G.1.3(12):   </FONT></B></P>
<UL><P>The input sequence is a pair of optionally signed real literals representing
the real and imaginary components of a complex value; optionally, the pair of
components may be separated by a comma and/or surrounded by a pair of
parentheses. Blanks are freely allowed before each of the components and before
the parentheses and comma, if either is used. If the value of the parameter
Width is zero, then
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>The input sequence is a pair of optionally signed real values representing the
real and imaginary components of a complex value. These components have the
format defined for the corresponding Get procedure of an instance of
Text_IO.Float_IO (see A.10.9) for the base subtype of Complex_Types.Real.
The pair of components may be separated by a comma or
surrounded by a pair of parentheses or both. Blanks are freely allowed before
each of the components and before the parentheses and comma, if either is used. If the
value of the parameter Width is zero, then
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The syntax of real literals read by Ada.Text_IO.Complex_IO.Get is the
same as that of Ada.Text_IO.Float_IO.Get.  The same applies to
Ada.Wide_Text_IO.Complex_IO.Get.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>The intent is that all input of real literals, as well as the 'Value
attribute, accept the same syntax.  This intent is reflected in
AARM G.1.3(1.a), which suggests implementing Complex_IO in terms of Float_IO.
</P>

<P><BR><BR></P>
<HR>

<A NAME="8652/0093"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0093 -  Only the current unit is affected by pragma Inspection_Point</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00207<BR>
Report Qualifier -- Clarification Required<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 H.3.2</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>In the standard, pragma Inspection_Point is not a configuration pragma.
However, consider the following example:
</P>
<PRE><TT><UL><B>procedure</B> P <B>is</B>
   A : Integer := 1;
<B>begin</B>
   Q;
   -- A is not used after this point
<B>end</B>;
</UL></TT></PRE>
<PRE><TT><UL><B>procedure</B> Q <B>is</B>
<B>begin</B>
   ...
   <B>pragma</B> Inspection_Point;
<B>end</B>;
</UL></TT></PRE>
<P>In our example A must be inspectable at the inspection point,
according to H.3.2(5).
</P>
<P>Must we be able to find the value of A, even if it is in a different
compilation unit? (No.) If so, the dead value must be stored before calling
Q. Or does pragma Inspection_Point apply only to objects in the
current compilation unit? (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Pragma Inspection_Point applies to all variables given as arguments
or, if there are no arguments, to all variables visible at the inspection
point.
</P>

<H4><FONT FACE="Arial, Helvetica">Corrigendum Wording</FONT></H4>
<P><B><FONT FACE="Arial, Helvetica">Replace  H.3.2(5):   </FONT></B></P>
<UL><P>An <I>inspection point</I> is a point in the object code corresponding to the
occurrence of a pragma Inspection_Point in the compilation unit. An object
is <I>inspectable</I> at an inspection point if the corresponding pragma
Inspection_Point either has an argument denoting that object, or has no
arguments.
</P></UL>
<P><B><FONT FACE="Arial, Helvetica">by:</FONT></B></P>
<UL><P>An <I>inspection point</I> is a point in the object code corresponding to the
occurrence of a pragma Inspection_Point in the compilation unit.
An object is <I>inspectable</I> at an inspection point if the corresponding
pragma Inspection_Point either has an argument denoting that object, or
has no arguments and the object is visible at the inspection point.
</P></UL>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A pragma Inspection_Point without parameters applies only to all variables
visible at the point.
</P>

<H4><FONT FACE="Arial, Helvetica">Discussion</FONT></H4>
<P>A pragma Inspection_Point with arguments requires that all the objects
listed be visible. It was the intent that a pragma Inspection_Point
without arguments be a convenient shorthand for listing all objects
which could have been given as arguments.
</P>
<P>It follows that a pragma Inspection_Point without arguments applies to
all those objects visible at that point.
</P>
<P>In the example the object A is not visible at the place of the pragma
and therefore its value need not be available.
</P>
<P>The pragma does not apply just to objects in the current compilation unit
since global objects in another compilation unit might be visible. Thus
consider
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
   A: Integer;
<B>private</B>
   B: Integer;
<B>end</B>;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> P;
<B>procedure</B> Q <B>is</B>
<B>begin</B>
   <B>pragma</B> Inspection_Point;
   ...
<B>end</B> Q;
</UL></TT></PRE>
<P>Since A is visible at the place of the pragma its value must be available
for inspection. The same does not apply to B.
</P>
<P>Notwithstanding the above, any compiler conforming to Annex H might have a
mode of operation that enables all global variables (visible or not) to be
inspected at any point.
</P>

<P></P>

</BODY>
</HTML>