File: defect2.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 (1510 lines) | stat: -rw-r--r-- 62,919 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
    <TITLE>Ada 95 Defect Reports - Part 2</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 2<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 contained in Ada Records of Response 1. 
Issues which resulted in wording changes to the standard are available in the 
companion document, <A HREF="defect1.html">Defect Reports Part 1</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/0094"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0094 -  Is normal termination an "external interaction"?</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Is the normal termination of a program with no function result or
parameters an external interaction? (Yes.)  It isn't defined as one in
1.1.3(9-14).
</P>
<P>In particular, the following main program has no external interactions
as defined in 1.1.3:
</P>
<PRE><TT><UL><B>procedure</B> Main <B>is</B>
<B>begin</B>
   <B>loop</B>
      <B>null</B>;
   <B>end</B> <B>loop</B>;
<B>end</B> Main;
</UL></TT></PRE>
<P>May an implementation optimize out the infinite loop? (No.)  The
resulting program also has no external interactions; the only
difference is that it terminates.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Termination of a program is considered an external interaction.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>1.1.3 (12) includes as an external interaction:
</P>
<P><UL>Any result returned or exception propagated from a main subprogram
(see 10.2) or an exported subprogram (see Annex B) to an external
caller.
</UL></P>
<P>10.2 (2) says that a main subprogram &quot;can be invoked from
outside the Ada implementation&quot;.  A.15 goes on to describe the
possible interactions of a main subprogram with the &quot;external
execution environment&quot;, including the possibility that a main
subprogram may return a status value.  In particular &quot;Normal
termination of a program returns as the exit status ... &quot;.
</P>
<P>The above wording must be understood as an attempt to define in
Ada terminology (&quot;invoked&quot;, &quot;result returned&quot;, and &quot;exception
propagated&quot;) interactions with an external execution environment
that is not itself governed by the standard.
</P>
<P>The International Standard does not (and cannot) define the exact manner of
invocation of a main subprogram by the external execution
environment, how parameters may be passed to it (if any), how the
main program may return status, or what activities in the external
environment may be triggered by termination of the main program
(whether normal or abnormal).  Therefore, unless a given
implementation can determine that a specific external environment
will not be affected by whether a given program terminates, the
Ada implementation must assume that it might.
</P>
<P>Even within the Ada domain, elimination of an infinite loop from a
subprogram is not an acceptable optimization.  For example,
consider the following:
</P>
<PRE><TT><UL><B>procedure</B> External_Environment <B>is</B>
   <B>procedure</B> Main <B>is</B>
   <B>begin</B>
      <B>loop</B>
         <B>null</B>;
      <B>end</B> <B>loop</B>;
   <B>end</B> Main;
<B>begin</B>
   Main;
   Explode_The_Bomb;
<B>end</B> External_Environment;
</UL></TT></PRE>
<P>No one would argue that it would be acceptable to delete the infinite
loop above, assuming that Explode_The_Bomb has some &quot;external
interaction&quot; as the name suggests.  By analogy, there is no reason
to presume that the external environment from which an Ada program
is invoked is not capable of expressing a dependence such as the
one above.
</P>

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

<A NAME="8652/0095"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0095 -  Unconstrained formal types</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>When is a generic formal subtype unconstrained?
</P>
<P>AARM 12.3(11.c) says:
</P>
<P><UL>A formal derived subtype is constrained if and only if
the ancestor subtype is constrained.  A formal array type
is constrained if and only if the declarations says so.
Other formal subtypes are unconstrained, even though they
might be constrained in an instance.
</UL></P>
<P>However, this does not seem to follow from the rules in the standard.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A formal private subtype without discriminants is constrained.
</P>
<P>An access subtype may be doubly constrained in a generic instance;
the constraint given in the subtype_indication overrides the
constraint (if any) that might have come from the actual subtype.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>3.2(9) says:
</P>
<P><UL>A subtype is called an unconstrained subtype if its type has
unknown discriminants, or if its type allows range, index, or discriminant
constraints, but the subtype does not impose such a constraint; otherwise,
the subtype is called a constrained subtype (since it has no unconstrained
characteristics).
</UL></P>
<P>Note the distinction between &quot;type&quot; and &quot;subtype&quot;.  An array type allows
an index constraint, for example, whereas an array subtype may or may
not impose one.
</P>
<P>Thus, AARM 12.3(11.c) is incorrect in the case of a subtype of a formal
private type with no discriminants.  Such a subtype is constrained,
because its type does not allow a discriminant constraint.
</P>
<P>This raises an interesting question:
</P>
<PRE><TT><UL><B>generic</B>
    <B>type</B> Str_Ptr <B>is</B> <B>access</B> String;
<B>package</B> GP <B>is</B>
    ...
<B>end</B> GP;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> GP <B>is</B>
    <B>subtype</B> Str_Ptr_10 <B>is</B> Str_Ptr(1..10); -- Legal?  (Yes.)
    X : Str_Ptr_10;
    ...
<B>end</B> GP;
</UL></TT></PRE>
<P>Str_Ptr is unconstrained, since an access type designating String allows
a constraint, and Str_Ptr does not impose one.  This implies that
3.7.1(7) allows the subtype_indication &quot;Str_Ptr(1..10)&quot;.  However,
the instance might try to impose a different constraint:
</P>
<PRE><TT><UL><B>type</B> Str_P <B>is</B> <B>access</B> String;
<B>subtype</B> Str_P_7 <B>is</B> Str_P(1..7);
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> P <B>is</B> <B>new</B> GP(Str_P_7); -- Legal?  (Yes.)
</UL></TT></PRE>
<P>12.3(11) says this is legal, since Legality Rules are not enforced in
the body of an instance.  Thus, the bounds of X are (1..10), and the
constraint (1..7) is effectively ignored.
</P>
<P>Note that if the declaration of Str_Ptr_10 were in the declaration of GP
instead of the body, then the instantiation P would be illegal, since
Legality Rules are enforced in the instance declaration.
</P>
<P>Note that if the two constraints ever &quot;meet&quot;, Constraint_Error will be
raised, as illustrated by the following modification of the above
example:
</P>
<PRE><TT><UL><B>generic</B>
    <B>type</B> Str_Ptr <B>is</B> <B>access</B> String;
    Obj: <B>in</B> <B>out</B> Str_Ptr;
<B>package</B> GP <B>is</B>
   <B>procedure</B> Bad;
<B>end</B> GP;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> GP <B>is</B>
    <B>subtype</B> Str_Ptr_10 <B>is</B> Str_Ptr(1..10);
    S: <B>aliased</B> String(1..10);
    X: Str_Ptr_10 := S'<B>access</B>;
</UL></TT></PRE>
<PRE><TT><UL>    <B>procedure</B> Bad <B>is</B>
    <B>begin</B>
       Obj := X; -- Constraint_Error is raised here.
    <B>end</B> Bad;
<B>end</B> GP;
</UL></TT></PRE>
<PRE><TT><UL><B>type</B> Str_P <B>is</B> <B>access</B> String;
<B>subtype</B> Str_P_7 <B>is</B> Str_P(1..7);
Actual_Obj: Str_P_7;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> P <B>is</B> <B>new</B> GP(Str_P_7, Actual_Obj);
...
P.Bad; -- This will propagate Constraint_Error.
</UL></TT></PRE>
<P>In the instance, Obj is constrained to (1..7), whereas X is constrained
to (1..10).  An attempt to assign one to the other (as in procedure Bad)
will fail the constraint check.
</P>
<P>An alternative rule would be that it is illegal to give a constrained
access subtype as the actual in the above case.  This would be a cleaner
rule, since it would avoid the anomaly of a doubly-constrained access
type.  However, most Ada 83 compilers probably allow the above example,
and make the bounds of X be (1..10), and since constraining an access
subtype is fairly uncommon, it does not seem worthwhile to use this
alternative rule.
</P>
<P>Note that it is irrelevant whether a formal scalar subtype is considered
constrained or unconstrained, since no compile-time rules are affected.
Constrained-ness of a scalar type has an effect at run-time, but at
run-time, only instances exist, not generic units.
</P>

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

<A NAME="8652/0096"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0096 -  Case sensitivity of Wide_Value and Value attributes</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>For S'Wide_Value in the case of a nongraphic character, 3.5(43) gives
the following condition under which the normal result is returned;
otherwise, Constraint_Error is raised:
&quot;...if the sequence of characters of the parameter (ignoring leading and
trailing spaces) has the syntax of an enumeration literal and if it
... corresponds to the result of S'Wide_Image for a nongraphic character
of the type...&quot;
</P>
<P>Is the use of the term &quot;corresponds&quot; intended to imply case
sensitivity?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>S'Wide_Value and S'Value are not case sensitive for nongraphic
characters.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A sequence of characters corresponds to the result of S'Wide_Image if it
is the same ignoring case.  Thus, S'Wide_Value is not case sensitive in
the case of a nongraphic character.  The same applies to S'Value.
</P>
<P>It is clearly the intent that the &quot;correspondence&quot; mentioned above be
case insensitive.  Thus, Character'Wide_Value(&quot;nul&quot;) does not raise
Constraint_Error, even though Character'Wide_Image returns &quot;NUL&quot; for the nul
character.
</P>

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

<A NAME="8652/0097"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0097 -  Controlled types in language-defined generic packages</FONT></H3>

<H4><FONT FACE="Arial, Helvetica">Working Reference Number  AI95-00115<BR>
Report Qualifier -- Clarification Requested<BR>
Section References<BR>
</FONT><FONT SIZE=-1>
 3.9.1;  7.6;  A</FONT></H4>

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>May an implementation declare a controlled type in its implementation of
a language-defined generic package?  (No.)  For example, may
Ada.Sequential_IO.File_Type be a controlled type?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A language-defined generic package may be instantiated at any nesting
depth. Hence, it cannot declare a controlled type.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A language-defined generic package may be instantiated at any nesting
depth. This follows from the fact that the standard does not say otherwise.
</P>
<P>This implies that the implementation of a language-defined generic
package cannot contain the declaration of a controlled type, since the
accessibility rules require that controlled types be declared at library
level.
</P>
<P>If an implementation wishes to implement, say,
Ada.Sequential_IO.File_Type in terms of a controlled type, it can
declare the controlled type in a separate (non-generic) package, such as
System.File_Implementation, and make type File_Type have a component
whose type is the controlled type.
</P>
<P>The implementation model given in AARM A.5.2(46.a), which calls for making
the Generator type of the random number packages a controlled type, is
wrong.  It should instead call for Generator to have a component of a
controlled type, declared in a (non-generic) package.
</P>

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

<A NAME="8652/0098"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0098 -  Primitive operations declared before it is known if the type is tagged</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Is a primitive operation of a type which is declared before it is known
that the type is tagged a dispatching operation? (Yes.)
</P>
<P>This question matters because 3.9.2(12) states that &quot;A given
subprogram shall not be a dispatching operation of two or more distinct
tagged types.&quot;
</P>
<P>Consider the following examples:
</P>
<PRE><TT><UL><B>package</B> P1 <B>is</B>
   <B>type</B> T1 <B>is</B> <B>private</B>;
   <B>type</B> T2 <B>is</B> <B>private</B>;
   <B>procedure</B> P (X1 : T1; X2 : T2); -- violates 3.9.2(12) ?  (Yes.)
<B>private</B>
   <B>type</B> T1 <B>is</B> <B>tagged</B> <B>null</B> <B>record</B>;
   <B>type</B> T2 <B>is</B> <B>tagged</B> <B>null</B> <B>record</B>;
<B>end</B>;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> P2 <B>is</B>
<B>private</B>
   <B>type</B> T1;
   <B>type</B> T2;
   <B>procedure</B> P (X1 : <B>access</B> T1; X2 : <B>access</B> T2);
      -- violates 3.9.2(12) ?  (Yes.)
<B>end</B>;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> P2 <B>is</B>
   <B>type</B> T1 <B>is</B> <B>tagged</B> <B>null</B> <B>record</B>;
   <B>type</B> T2 <B>is</B> <B>tagged</B> <B>null</B> <B>record</B>;
<B>end</B>;
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Consider a type whose partial view is untagged, but whose full view is
tagged.  A primitive subprogram declared for the partial view is a
dispatching subprogram of the full view.
</P>
<P>Therefore, if there are two types, T1 and T2, and there is a primitive
subprogram of both:
</P>
<PRE><TT><UL><B>procedure</B> Primitive(X: T1; Y: T2);
</UL></TT></PRE>
<P>then it is illegal for both T1 and T2 to be tagged, even if the full
type declarations occur after Primitive.
</P>

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

<A NAME="8652/0099"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0099 -  Operators not inherited from root numeric types</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider the operators described in 4.5.5(17), such as
</P>
<PRE><TT><UL><B>function</B> &quot;*&quot; (Left: root_real; Right: root_integer) <B>return</B> root_real;
</UL></TT></PRE>
<P>It would seem logical to assume that root_real is declared immediately
within the visible part of package Standard, which means that this operator
is a primitive subprogram of type root_real.
</P>
<P>By 3.5.6(3), Float is derived from root_real.  Does Float therefore
inherit this operator?  (No.)  If so, the following function exists:
</P>
<PRE><TT><UL><B>function</B> &quot;*&quot; (Left: Float; Right: root_integer) <B>return</B> Float;
</UL></TT></PRE>
<P>which would make the following legal:
</P>
<PRE><TT><UL><B>declare</B>
   X: Float;
<B>begin</B>
   ...
   X := X * 2; -- Legal?  (No.)
<B>end</B>;
</UL></TT></PRE>
<P>The same applies to a user-defined numeric type.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Predefined operators, including those of the root numeric types, are not
inherited.  Instead, types have predefined operators by specific
language rules.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Although floating point types are derived from root_real, this does not
imply any inheritance of subprograms.  Inheritance happens for a derived
type that is declared by a derived_type_definition, by 3.4(7).  For
private extensions, 7.3(16) and 12.5.1(20) apply.  No such rules apply
to other kinds of type_definition; therefore, no inheritance takes place
for such types.
</P>
<P>Section 4 explicitly defines the predefined operators that are
implicitly declared for a type, according to its class.  The mechanism
of inheritance is not used for this purpose.
</P>
<P>Note that this is not the only way in which the implicit derivation from
a root numeric type is different from derivation via an explicit
derived_type_definition.  See, for example, 3.5.4(14) and AARM 3.5.4(14.a).
</P>

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

<A NAME="8652/0100"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0100 -  Inconsistency with Ada 83 in the definition of exponentiation</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>4.5.6(11) says:
</P>
<P>The expression X ** N with the value of the exponent N positive is
equivalent to the expression X *
X * ... X (with N-1 multiplications) except
that the multiplications are associated in an arbitrary order.
</P>
<P>However, Ada 83 required left-to-right associations.  Is this an upward
inconsistency? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The multiplications of an exponentiation are associated in an arbitrary
order.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Ada 83 required left-to-right associations, and AI83-00137 confirmed this.
AI83-00868 allowed arbitrary association, but AI83-00868 was never formally
approved.  Hence, this represents an upward inconsistency, and should
have been so documented in the AARM.
</P>

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

<A NAME="8652/0101"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0101 -  Conversions between access types with different representations</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>It is possible to declare types that are normally convertible,
but that have a pragma Convention that makes some such conversions
impossible or impractical.  For instance,
</P>
<PRE><TT><UL><B>type</B> Ada_Ptr <B>is</B> <B>access</B> Integer; -- Integer is C-compatible in this
                                -- implementation.
<B>type</B> C_Ptr <B>is</B> <B>new</B> Ada_Ptr;
<B>pragma</B> Convention (C, C_Ptr);
</UL></TT></PRE>
<P>The value sets of such convertible types may not completely overlap.
For example, on a machine that is not 8-bit-byte addressable, an Ada_Ptr
might be represented as a normal address, whereas a C_Ptr might be
represented as a bit-field pointer of some sort.
</P>
<P>What should happen when a value of C_Ptr has no corresponding value in
Ada_Ptr?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>If the Convention (other than Ada) of an access type has been specified
by the user, then the semantics of type conversions involving that
access type are implementation defined.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The semantics of such conversions are implementation defined.  This
follows from the fact that pragma Convention is a representation pragma
(B.1(29)), and implementations can interpret representation pragmas
however they want and place restrictions on them (13.1(20)), except when
there are explicit rules to the contrary.  This is also stated in the
NOTE of B.1(43).  So it's perfectly acceptable to raise an exception
when a given operation doesn't make sense.
</P>
<P>This is clearly desirable, since the goal of interfacing to another
language is to match the representations chosen by the implementation of
the other language, and doing so can make it impossible or impractical
to obey the &quot;normal&quot; (non-interfaced) Ada semantics.
</P>

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

<A NAME="8652/0102"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0102 -  Visibility of inherited private components</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    <B>type</B> Parent <B>is</B> <B>tagged</B> <B>private</B>;
<B>private</B>
    <B>type</B> Parent <B>is</B>
        <B>record</B>
            C: Integer;
        <B>end</B> <B>record</B>;
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> P; <B>use</B> P;
<B>package</B> Q <B>is</B>
    <B>type</B> Child <B>is</B> <B>new</B> Parent <B>with</B>
        <B>record</B>
            C: Integer;
        <B>end</B> <B>record</B>;
<B>end</B> Q;
</UL></TT></PRE>
<PRE><TT><UL><B>with</B> Q; <B>use</B> Q;
<B>package</B> P.Child <B>is</B>
    <B>type</B> Grandchild <B>is</B> <B>new</B> Q.Child <B>with</B> <B>null</B> <B>record</B>;
    X: Grandchild;
    ... X.C ...
<B>end</B> P.Child;
</UL></TT></PRE>
<P>What is the meaning of X.C, given that Grandchild is declared in a place
where the full view of Parent is visible?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Consider types Parent, Child, and Grandchild, derived from one another
in that order.  The components of Child are determined where Child is
declared.  If, at the place where Grandchild is declared, additional
components of Parent are visible (that were not visible to Child), then
Grandchild does <I>not</I> inherit them as visible components.  One can
convert from Grandchild to Parent in order to manipulate these
components.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>There is a general design principle in Ada that you can never have more
visibility into the components or operations of a type than in the package
where the type
is declared.  Effectively, the components and operations of a type are
&quot;frozen&quot; to be those visible somewhere within the &quot;immediate&quot; scope of
the type.  Even if you go into a package that knows more about the
ancestors of the type, that doesn't change the set of components or
primitives that the type has.
</P>
<P>So in the above example, the type Child is declared in a place where
there is no visibility on the C component of Parent; hence this
component is not declared, and it is legal to declare another,
unrelated, C component in Child.  Thus, X.C refers to the C component
declared in Child.  This is despite the fact that at the point of &quot;X.C&quot;,
it <I>is</I> visible that Child is derived from Parent, and it <I>is</I> visible
that Parent has a component called C.  To refer to the C component from
Parent, one would write Parent(X).C.
</P>
<P>The C component from Parent does exist, despite the fact that it is not
visible.
</P>
<P>This paradox of knowing the ancestry of a type, but not being able to
take advantage of it except through explicit conversion, also applied to
derived types in Ada 83.  It is based on the general notion that even
inherited operations and components need to have a point of declaration,
and that point of declaration is required to be in the immediate scope
of the derived type.  If there is no place where such implicit
declarations could occur, then the corresponding operations or
components are not inherited.  (Of course, inherited operations get
declared (if at all) in the declarative region containing the type,
whereas components get declared (if at all) in the declarative region of
the type itself.)
</P>
<P>See 7.3.1 and AARM-7.3.1(7.a-7.r).
</P>
<P>Consider the following modified example:
</P>
<PRE><TT><UL><B>package</B> P <B>is</B>
    <B>type</B> Parent <B>is</B> <B>tagged</B> <B>private</B>;
<B>private</B>
    <B>type</B> Parent <B>is</B>
        <B>record</B>
            C: Integer;
        <B>end</B> <B>record</B>;
<B>end</B> P;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> P.Q <B>is</B>
    <B>type</B> Child <B>is</B> <B>new</B> Parent <B>with</B>
        <B>record</B>
            C: Integer; -- Illegal!
        <B>end</B> <B>record</B>;
<B>end</B> P.Q;
</UL></TT></PRE>
<P>The above example is illegal, because in this case Child <I>does</I> inherit
C from Parent, so the second declaration of C is an illegal homograph.
</P>

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

<A NAME="8652/0103"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0103 -  Type descriptors can be laid out at compile time</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>The rules in 7.3.1 imply that for a type declared in a
package_declaration, certain inherited subprograms can be declared in
the package_body.  How does this correspond to the intended
implementation model of AARM 3.9(1.a-1.b)?
</P>
<P><UL>The intended implementation model is for a tag to be
represented as a pointer to a statically allocated and link-time
initialized type descriptor.  The type descriptor contains the
address of the code for each primitive operation of the type.  It
probably also contains other information, such as might make
membership tests convenient and efficient.
</UL></P>
<P><UL>The primitive operations of a tagged type are known at its
first freezing point; the type descriptor is laid out at that point.
It contains linker symbols for each primitive operation; the linker
fills in the actual addresses.
</UL></P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>It is possible (and desirable) for an
implementation to allocate and initialize type descriptors statically.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Although the inherited subprogram might be declared in the package_body,
the fact that it is going to be declared there is known at compile time
of the package_declaration.  Thus, there is no conflict with the
above-mentioned implementation model.
</P>

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

<A NAME="8652/0104"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0104 -  Finalization and Unchecked_Deallocation</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>13.11.2(9) says that Free first performs finalization, then deallocates
the storage.  7.6.1(17) says that (if Finalize propagates an exception,)
Program_Error is raised after any other finalizations are performed.
</P>
<P>In the case where Finalize propagates an exception, is the storage
deallocated?  Is it possible that Finalize will be called again on the
same object?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Consider an instance Free of Unchecked_Deallocation for a type with
controlled parts.  Free will first finalize its parameter.  If some
Finalize propagates an exception, then it is unspecified whether storage
is deallocated, and whether the object ceases to exist.  Finalize might
be called again on that same object.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The standard leaves this issue unspecified.  There are three alternatives:
</P>
<P>Alternative 1:
</P>
<P>Storage is deallocated, and the object ceases to exist.  Finalize will
not be called again on that same object.
</P>
<P>Alternative 2:
</P>
<P>It is unspecified whether storage is deallocated.  However, the object
ceases to exist; Finalize will not be called again on that same object.
</P>
<P>Alternative 3:
</P>
<P>It is unspecified whether storage is deallocated, and whether the object
ceases to exist.  Finalize might be called again on that same object.
</P>
<P>We choose Alternative 3, because this eases the burden on
implementations, and because a Finalize that propagates an exception is
a serious bug anyway.  If there is a desire to recover from such
situations, programmers should either prove that no such exception can
happen, or put a &quot;when others =&gt;&quot; clause in each Finalize procedure.
</P>

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

<A NAME="8652/0105"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0105 -  Can an abstract subprogram be renamed?</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Can an abstract subprogram be renamed? (Yes.) Can a subprogram which
must be overridden in the sense of 3.9.3(6) be renamed? (No.)
</P>
<P>Consider an example with an abstract parent type and a primitive operation.
8.5.4(8) says that the renaming uses the original inherited subprogram, not
the overriding version.
</P>
<PRE><TT><UL><B>package</B> Types <B>is</B>
   <B>type</B> T <B>is</B> <B>abstract</B> <B>tagged</B> ...
   <B>procedure</B> P (F : T) <B>is</B> <B>abstract</B>;
<B>end</B> Types;
<B>package</B> Extensions <B>is</B>
   <B>type</B> E <B>is</B> <B>new</B> Types.T <B>with</B> ...
   <B>procedure</B> Pr (F : E) <B>renames</B> P;  -- renaming of inherited P
                                    -- Legal? (No.)
   <B>procedure</B> P  (F : E);
<B>end</B> Extensions;
</UL></TT></PRE>
<P>A similar example can be constructed with a function with a controlling
result.
</P>
<PRE><TT><UL><B>package</B> Types <B>is</B>
   <B>type</B> T <B>is</B> <B>tagged</B> ...
   <B>function</B> F <B>return</B> T;
<B>end</B> Types;
<B>package</B> Extensions <B>is</B>
   <B>type</B> E <B>is</B> <B>new</B> Types.T <B>with</B> ...
   <B>function</B> Fr <B>return</B> E <B>renames</B> F;  -- renaming of inherited F
                                    -- Legal? (No.)
   <B>function</B> F  <B>return</B> E;
<B>end</B> Extensions;
</UL></TT></PRE>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An abstract subprogram can be renamed, and the renamed view is also
abstract. Such a renaming must appear in a place where the declaration
of an abstract subprogram would be legal. Similarly, the &quot;shall be overridden&quot;
property of 3.9.3(6) applies to a renamed view. Thus, any renaming of an
inherited subprogram that must be overridden is illegal.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The intent of the language is that an abstract subprogram can be renamed,
and the renamed view is also abstract. All of the rules about declaring
abstract subprograms apply at the point of the renaming (in particular,
3.9.3(3)).
</P>
<P>Similarly, it is possible to write a renaming of an inherited subprogram
which must be overridden because of the rules of 3.9.3(6). The intent
of the language is that the &quot;shall be overridden&quot; property also applies
to the renamed view. However, it is not possible to give an overriding
for the renamed view (as the overriding specification would be an illegal
homograph of the renamed subprogram). Thus, any renaming of an inherited
subprogram that must be overridden is illegal.
</P>

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

<A NAME="8652/0106"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0106 -  Daylight savings and Ada.Calendar</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Suppose an implementation chooses to keep Calendar.Clock in some
canonical form, such as GMT, and that it also chooses to support
daylight savings time, by making Split and Time_Of do the appropriate
conversions.  Is this a valid implementation?  (Yes.)
</P>
<P>If so, what should Split do when daylight savings time ends in the fall,
given that there are two different Time values for some
Year/Month/Day/Second values?  And what should Time_Of do when daylight
savings time starts in the spring, given that there are
Year/Month/Day/Second values that do not correspond to any Time?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The values returned by Split and Time_Of are implementation defined at
the boundaries of daylight savings time (assuming daylight savings time
is supported by the implementation).
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>9.6(24,26) say:
</P>
<P><UL>The functions Year, Month, Day, and Seconds return the corresponding
values for a given value of the type Time, as appropriate to an
implementation-defined timezone; the procedure Split returns all four
corresponding values.  Conversely, the function Time_Of combines a year
number, a month number, a day number, and a duration, into a value of type
Time.  The operators &quot;+&quot; and &quot;-&quot; for addition and subtraction of times and
durations, and the relational operators for times, have the conventional
meaning.
</UL></P>
<P><UL>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.
</UL></P>
<P>9.6(24) uses the phrase &quot;as appropriate to an implementation-defined
timezone&quot;.  The implementation is free to do daylight-savings-processing
as part of its time zone handling, so the implementation suggested in
the question above is valid.  Since it explicitly says &quot;implementation
defined&quot;, the implementation can do what it wants, so long as the
behavior is documented.
</P>
<P>When implementing Ada on an operating system that supports time zones,
it makes sense to implement the Ada operations in terms of the
corresponding operating system operations.  It is not reasonable to
require Ada programs to do something different from other programs on
that system.  Nor is it reasonable to require an Ada implementation to
re-implement this processing.
</P>
<P>9.6(26) might be taken as a requirement that Time_Error be raised by
Time_Of in the spring.  However, the standard does not define what is meant by
a &quot;proper date&quot;.  Clearly, February 31 is not a &quot;proper date&quot; -- the
term is not entirely meaningless -- but surely the term is vague enough
to allow the Ada implementation to use the underlying operating system's
notion of &quot;proper date&quot; with respect to the questionable cases
considered here.  Furthermore, raising Time_Error is probably
undesirable, since it is more likely to cause an Ada program to
malfunction in rare cases, than to catch a bug in the program.
</P>

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

<A NAME="8652/0107"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0107 -  Pragma Elaborate for child units</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>10.2(9) says:
</P>
<P><UL>The order of elaboration of library units is determined
primarily by the elaboration dependences.  ... In addition,
if a given library_item or ... has a pragma Elaborate ...
that MENTIONS another library_unit, then there is an elaboration
dependence of the given library_item upon the body of the other
library_unit, ...
</UL></P>
<P>10.1.2(6) states:
</P>
<P><UL>A library_item is MENTIONED in a with_clause if it is denoted
by a library_unit_name or a prefix in the with_clause.
</UL></P>
<P>Is the term &quot;mentioned&quot; as used in 10.2(9) meant to be defined by
10.1.2(6)? (No.)  If so, it would imply that a pragma Elaborate on a child unit
causes an elaboration dependence upon the parent of that child unit (as
well as on the child unit itself).  Is this the intent?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A pragma Elaborate on a child unit does not imply an elaboration
dependence upon the parent of that child unit.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The intent is that 10.1.2(6) is defining &quot;mentioned in a with_clause&quot;,
not &quot;mentioned&quot; in general.  The term &quot;mentioned&quot; in 10.2(9) is used in
an informal sense; it merely means the library unit to which the pragma
applies, and not its parent.
</P>
<P>10.2.1(26) clarifies this:
</P>
<P><UL>A pragma Elaborate specifies that the body of the named library
unit is elaborated before the current library_item.
</UL></P>
<P>If transitive semantics is desired, then pragma Elaborate_All should be
used.
</P>

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

<A NAME="8652/0108"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0108 -  Separate compilation of generic bodies</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>10.1.4(3) states that the mechanisms for replacing compilation units
within an environment are implementation defined.  Is it intended
that &quot;mechanisms&quot; also means &quot;circumstances&quot;? (No.)
</P>
<P>This seems to be partly contradicted by NOTE 7 in 10.1.4(10)
which prevents automatic removal of units that instantiate a
generic body being replaced.
</P>
<P>This NOTE however, does not seem to follow from any normative statement.
10.1.4(7) allows removal of compilation units that depend upon a
given one, but nothing apparently prevents removal of compilation units
that don't have such a dependency.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The NOTE in 10.1.4(10), which says that separate compilation of generic
bodies is required, is correct.  This implies that an implementation
must be capable of detecting legality errors in a compilation unit that
instantiates a generic unit, without seeing the generic body.  It does
<I>not</I> imply that the compiler must generate code without seeing the
generic body.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>10.1.4(3) is simply saying that the &quot;commands&quot; or &quot;mouse clicks&quot; that
the user gives to perform various actions are implementation defined.
It is not intended as a permission for the implementation to arbitrarily
remove compilation units from the environment.
</P>
<P>10.1.4(7) says when compilation units can be automatically removed,
and this list is intended to be complete.
</P>
<P>An implementation may, of course, have additional commands for removing
compilation units, or performing any other actions on the environment.
</P>

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

<A NAME="8652/0109"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0109 -  Matching rules for generic formal access-to-constant types</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>12.5.4(4) states that &quot;If and only if the general_access_modifier
constant applies to the formal, the actual shall be an access-to-constant
type&quot;.  Is it really intended to forbid an access-to-variable
type from being passed as an actual to a generic formal
access-to-constant type?  (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An access-to-variable type cannot be passed as an actual to a generic
formal access-to-constant type.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Consider the following example:
</P>
<PRE><TT><UL><B>type</B> Actual <B>is</B> <B>access</B> <B>all</B> Integer;
X: <B>aliased</B> <B>constant</B> Integer;
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
    <B>type</B> Formal <B>is</B> <B>access</B> <B>constant</B> Integer;
<B>package</B> Gp <B>is</B>
    <B>function</B> F <B>return</B> Formal;
<B>end</B> Gp;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> <B>body</B> Gp <B>is</B>
    <B>function</B> F <B>return</B> Formal <B>is</B>
    <B>begin</B>
        <B>return</B> X'<B>access</B>;
    <B>end</B> F;
<B>end</B> Gp;
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> Ip <B>is</B> <B>new</B> Gp (Formal =&gt; Actual); -- Illegal.
</UL></TT></PRE>
<P>If the above were legal, then Ip.F would produce an access-to-variable
value designating a constant, thus allowing a constant to be modified.
This would be very bad.  Hence, the &quot;if and only if&quot; wording of
12.5.4(4).
</P>

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

<A NAME="8652/0110"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0110 -  Order of Size and Small clauses for fixed point types</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider:
</P>
<PRE><TT><UL><B>type</B> Two_Bits_Spare <B>is</B> <B>delta</B> 4*System.Fine_Delta <B>range</B> -1.0..+1.0;
<B>for</B> Two_Bits_Spare'Size <B>use</B> Size_For_Fine_Delta - 2; -- Legal? (Maybe.)
</UL></TT></PRE>
<P>where Size_For_Fine_Delta is the number of bits needed for a type whose
delta is Fine_Delta.  Does the Size clause force the implementation to
choose the small of the type such that only Size_For_Fine_Delta - 2 bits
are needed?  (No.)
</P>
<P>13.3(55) says that 'Size should/must be &quot;the number of bits needed to
represent each value belonging to the subtype ...&quot;  and that an
implementation should/must support a specified 'Size for a first subtype
that reflects this representation.
</P>
<P>3.5.9(8) says &quot;the set of values of a fixed-point type comprise[s] the
integral multiples of a number called the small of the type&quot; which if
not specified &quot;is an implementation-defined power of two ...&quot;
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A Size clause does not determine the values of an ordinary fixed point
type.  The values are determined either by the implementation, or by a
Small clause; the legality of a Size clause is determined in part by the
values chosen.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A Size clause does not determine the values of an ordinary fixed point
type.  The values are determined either by the implementation, or by a
Small clause; the legality of a Size clause is determined in part by the
values chosen.
</P>
<P>Since there is no Small clause in the above example, 3.5.9(8) allows the
implementation to choose among various powers of two as the small, and the
small determines what the values of the type are.  A Size clause is
required to specify enough bits to represent all those values.  Thus,
the Size clause in the above example is legal if the implementation
chooses small to be 4*System.Fine_Delta, but is illegal if the implementation
chooses small to be System.Fine_Delta.
</P>

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

<A NAME="8652/0111"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0111 -  Storage pools and access types designating task types</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>If a user-defined storage pool is specified for an access-to-task type,
does this imply that the user's storage pool will be used for all data
structures associated with the task, such as the TCB and the task stack?
(No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The specification of a user-defined storage pool for an access-to-task type
permits the user-defined allocation and deallocation of task objects,
not necessarily of the implementation-defined tasking structures that support
the task object.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>Many implementations choose to implement a task object as an access to the
implementation-defined data structures associated with the task (such
as a Task Control Block (TCB) and a task stack). In such an implementation,
a user-defined storage pool will control only the allocation of the task
objects (i.e. the access object), and will have no effect on the allocation
and deallocation of those other resources.
</P>
<P>Note that in some such systems, it may be impossible to allow
user-defined allocation of TCBs via the storage pool mechanism, because
the TCBs are in a separate address space, or are allocated in a run-time
system table.
</P>

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

<A NAME="8652/0112"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0112 -  A box for a formal subprogram_default freezes the actual</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Consider:
</P>
<PRE><TT><UL><B>type</B> T <B>is</B> ....
<B>type</B> T2 <B>is</B> ...
<B>function</B> &quot;+&quot;(A: T; B: T2) <B>return</B> T;
</UL></TT></PRE>
<PRE><TT><UL><B>generic</B>
    <B>type</B> FT <B>is</B> <B>private</B>;
    <B>with</B> <B>function</B> &quot;+&quot;(A: FT; B: T2) <B>return</B> FT <B>is</B> &lt;&gt;;
<B>package</B> GP <B>is</B> ...
</UL></TT></PRE>
<PRE><TT><UL><B>package</B> IP <B>is</B> <B>new</B> GP(T);
    -- does this instantiation freeze &quot;+&quot; and therefore T2? (Yes.)
</UL></TT></PRE>
<P>13.14(5) doesn't cover that case.
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>A box for a formal subprogram_default freezes the actual subprogram
determined in an instantiation.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>A box for a formal subprogram_default freezes the actual subprogram
determined in an instantiation.
</P>
<P>12.6(10) says, &quot;If a generic unit has a subprogram_default specified by
a box, and the corresponding actual parameter is omitted, then it is
equivalent to an explicit actual parameter that is a usage name
identical to the defining name of the formal.&quot;
</P>
<P>Thus, the instantiation GP(T) is equivalent to the instantiation GP(T, &quot;+&quot;).
</P>
<P>13.14(4,5,14) then demand that &quot;+&quot; and T2 are frozen by the
instantiation.
</P>

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

<A NAME="8652/0113"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0113 -  Saving and restoring Current_Output</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>It's clear from the example in section A.4.3 of the Rationale that one
should be able to use the subprograms Current_Output and Set_Output
to save and restore Text_IO's current output file, using an object
of type File_Access.  However, given what I believe to be a typical
implementation of Text_IO, this won't work.
</P>
<P>Assume that Text_IO declares a hidden aliased object of type File_Type,
called, say, Current_Output_Object.  (How the type File_Type is declared
is irrelevant here; it may be a pointer, a descriptor record, a descriptor
number, or whatever, as long as the view from the body of Text_IO is
not limited.)  The bodies of the Current_Output and Set_Output functions
can then simply be:
</P>
<PRE><TT><UL><B>procedure</B> Set_Output (File : <B>in</B> File_Type) <B>is</B>
<B>begin</B>
   Current_Output_Object := File;
<B>end</B> Set_Output;
</UL></TT></PRE>
<PRE><TT><UL><B>function</B> Current_Output <B>return</B> File_Type <B>is</B>
<B>begin</B>
   <B>return</B> Current_Output_Object;
<B>end</B> Current_Output;
</UL></TT></PRE>
<PRE><TT><UL><B>function</B> Current_Output <B>return</B> File_Access <B>is</B>
<B>begin</B>
   <B>return</B> Current_Output_Object'<B>access</B>;
<B>end</B> Current_Output;
</UL></TT></PRE>
<P>Recall that the example in Rationale-A.4.3 looks like this:
</P>
<PRE><TT><UL><B>procedure</B> P(...) <B>is</B>
   New_File     : File_Type;
   Old_File_Ref : <B>constant</B> File_Access := Current_Output;
<B>begin</B>
   Open(New_File, ...);
   Set_Output(New_File);
   -- use the new file
   Set_Output(Old_File_Ref.all);
   Close(New_File);
<B>end</B> P;
</UL></TT></PRE>
<P>If we are using the Text_IO implementation above, Old_File_Ref will be
initialized to point to Current_Output_Object, the first call to Set_Output
will change the value of Current_Output_Object, the second call to Set_Output
will have no effect, and the Close will close a file that's still being
used as the current output file. Thus any operations on Current_Output
after the call to P will be erroneous by A.10.3(23).
</P>
<P>Is the suggested implementation of Text_IO legal? (No.) If so, the example
in the Rationale is non-portable. If not, how can the prohibition be
inferred from the International Standard?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Current_Output and Set_Output can be used to save and restore Text_IO's
current output file, using an object of type File_Access.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The suggested implementation is wrong.
</P>
<P>A.7(2) states, &quot;In the remainder of this section, the term file is
always used to refer to a file object....&quot;  A.10(5) states, &quot;At the
beginning of program execution the default input and output files are the
so-called standard input file and standard output file.&quot;  By A.7(2), this
can be paraphrased as follows:  &quot;At the beginning of program execution
the default input and output file objects are the so-called standard
input file object and standard output file object.&quot;  That is, the terms
&quot;default input file object&quot; and &quot;default output file object&quot; are not
names of distinct file objects, but of a <I>role</I> played by a file object.
That is, the only way that a single file object can be both the standard
input file and the default input file is if the default input file is not
a file object distinct from all other file objects.  (The role played by
the file objects currently acting as the default objects is described by
A.10(4):  &quot;If no file is specified, a default input file or a default
output file is used.&quot;  This is the closest the International Standard comes
to defining what a default file is, and the terms should probably have
been italicized.)
</P>
<P>It follows that Current_Output and Set_Output can be used to save and restore
Text_IO's current output file, using an object of type File_Access.
</P>

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

<A NAME="8652/0114"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0114 -  Mapping between Interfaces.C.char and Standard.Character</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>B.3(46) states that To_Ada and To_C map between Character and
char, but does not explain how.  Presumably, Interfaces.C.char
corresponds to the C type char, i.e., to the native character set of the
target machine.  Type Character, of course, always corresponds to
Latin-1, regardless of the target machine.  On an EBCDIC machine, does
To_C('A') yield the C.Interfaces.char value corresponding to EBCDIC 'A',
or does it yield the character whose EBCDIC code is Character'Pos('A')?
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>The To_C and To_Ada functions in Interfaces.C map between corresponding
characters, not necessarily between characters with the same internal
representation.  Corresponding characters are characters defined by the
same enumeration literal, if such exist; otherwise, the correspondence
is not defined by the language.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The intent is that 'A' maps to 'A', even if the two 'A's have
different representations.
</P>
<P>The following definition is equivalent to the above summary:
</P>
<P><UL>To_C (Latin_1_Char) = char'Value(Character'Image(Latin_1_Char))
provided that char'Value does not raise an exception;
otherwise the result is not defined by the language.
</UL></P>
<P><UL>To_Ada (Native_C_Char) = Character'Value(char'Image(Native_C_Char))
provided that Character'Value does not raise an exception;
otherwise the result is not defined by the language.
</UL></P>

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

<A NAME="8652/0115"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0115 -  Ada.Task_Identification.Is_Callable for the environment task</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>What is the behavior of Ada.Task_Identification.Is_Callable for the
environment task? In particular, does it change in value from True to False
when the main subprogram exits and starts waiting for library-level tasks
to terminate? (Yes.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>Ada.Task_Identification.Is_Callable called with a Task_Id value designating
the environment task returns True while the main subprogram is executing and
False once the main subprogram has returned and the environment task starts
waiting for library-level tasks to terminate.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The NOTE C.7.1(21) says that Ada.Task_Identification.Current_Task can return a
Task_Id value designating the environment task. 9.8(2) specifies that
Is_Callable returns True unless the task is completed or abnormal. The
structure of the environment task given in 10.2(10-12), and the dynamic
semantics of 10.2(25) tell us that the environment task is completed before
waiting for dependent tasks. The erroneous execution case of C.7.1(18)
should not apply, as the environment task continues to exist until the
partition terminates.
</P>
<P>Therefore, the value of Ada.Task_Identification.Is_Callable is well defined.
It is possible to test the value after the completion of the environment
task in a library-level task (while the environment task is waiting for
dependent tasks to terminate). Thus it cannot be implemented purely as a
return of True at all times.
</P>
<P>The Ada.Task_Identification.Is_Callable flag can be useful, as a
library-level task can use the value to terminate itself once the
partition has completed. This is especially important to bullet-proof a
reusable package containing a library task. At least one commercial Ada
library uses this technique.
</P>

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

<A NAME="8652/0116"></A>
<H3><FONT FACE="Arial, Helvetica">8652/0116 -  One queuing policy per partition</FONT></H3>

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

<H4><FONT FACE="Arial, Helvetica">Question</FONT></H4>
<P>Implementation Permissions D.4(15) says:
</P>
<P><UL>Implementations are allowed to define other queuing policies, but need
not support more than one such policy per partition.
</UL></P>
<P>Does the permission to support only one policy per partition apply only
to the &quot;other&quot; (implementation defined) policies?  (No.)
</P>

<H4><FONT FACE="Arial, Helvetica">Summary of Response</FONT></H4>
<P>An implementation need not support more than one queuing policy per
partition.  For example, the implementation need not support both
FIFO_Queuing and Priority_Queuing in the same partition.
</P>

<H4><FONT FACE="Arial, Helvetica">Response</FONT></H4>
<P>The second part of the Implementation Permission applies to all queuing
policies.
</P>
<P>10.1.5(9) says:
</P>
<P><UL>An implementation may place restrictions on configuration pragmas, so
long as it allows them when the environment contains no library_items other
than those of the predefined environment.
</UL></P>
<P>This implies that an implementation need not support more than one
queuing policy per partition, whether or not the policy is
implementation defined.  Of course, the &quot;other&quot; policies mentioned in
D.4(15) are implementation defined, so the implementation can restrict
them in any way it sees fit.  Required support for more than one policy
in the same partition would be an implementation burden that is not
worthwhile.
</P>

<P></P>

</BODY>
</HTML>