CVS difference for ais/ai-00269.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00269.txt

--- ais/ai-00269.txt	2004/09/04 01:13:43	1.6
+++ ais/ai-00269.txt	2004/09/14 01:25:57	1.7
@@ -1,4 +1,7 @@
-!standard  4.09 (29)                                   01-09-20  AI95-00269/03
+!standard  4.09 (35)                                   04-09-13  AI95-00269/04
+!standard  4.09 (37)
+!standard  4.09 (38)
+!standard 12.04 (10)
 !class binding interpretation 01-02-22
 !status work item 01-05-25
 !status received 01-03-23
@@ -9,16 +12,23 @@
 
 !summary
 
-If a formal in object is associated with a static actual, uses of the formal
-object declared in an instance outside of that instance are static.
+The name of a formal in object associated with a static actual denotes
+a static constant in an instance.
 
+The restrictions of 4.9(34-36) apply in the private part of an instance.
+
+The accuracy requirement of 4.9(38) does not apply in an instance body.
+
+If a static expression is not part of a larger static expression and
+its expected type is a universal type or any integer or real type, then
+the value of the expression can be arbitrarily large or small.
+
 !question
 
 Is the use of a formal object within a generic instance treated as static if
-the formal object is associated with a static actual? (Yes, when used outside
-of the instance.)
+the formal object is associated with a static actual? (Yes.)
 
-Consider the following example:
+Consider the following examples:
 
 procedure Ex_1 is
 
@@ -41,6 +51,33 @@
    end case;
 end Ex_1;
 
+procedure Ex_2 is
+
+   generic
+      type T is range <>;
+      One  : T;
+      Zero_A : T;
+      Zero_B : T;
+   package Gen_2 is
+      Bang : T := One / Zero_A;
+   end Gen_2;
+
+   package body Gen_2 is
+      Bang_Bang : T := One / Zero_B;
+   end Gen_2;
+
+   package New_Gen_2_A is new Gen_2 (Integer, 1, Zero_A => 0, Zero_B => -1);
+
+   --  Is this instantiation illegal, because of division by zero? (Yes.)
+
+   package New_Gen_2_B is new Gen_2 (Integer, 1, Zero_A => -1, Zero_B => 0);
+
+   --  Is this instantiation illegal, because of division by zero? (No.)
+
+begin
+   null;
+end Ex_2;
+
 !recommendation
 
 (See summary.)
@@ -61,27 +98,85 @@
 
 Thus, formal objects with static actual expressions should be treated as
 static in the instance. However, we need to be careful. We do not want to
-require exact evaluation for expressions static because of a formal object
-inside of the generic unit, because that would interfere with generic sharing.
-We also do not want to trigger any of the other rules of 4.9(34-38).
-All of these would require evaluating the expression when the generic is
-instantiated, which would introduce a body dependence.
+require exact evaluation for expressions inside the generic body which are
+static because they reference a formal object, since that would interfere
+with generic sharing.
+
+We also do not want to trigger any of the other rules of 4.9(34-38) in
+an instance body. All of these would require evaluating the expression
+when the generic is instantiated, which would introduce a body dependence.
+It's desirable for those rules to be applied in the private of an instance,
+since the private part is available to child units. So these rules will
+apply throughout the specification of an instance.
 
 Note that generic formal objects cannot be used in a context where a static
 expression is required inside of the generic, as legality rules are checked
 in the generic unit based on the properties of the formal (see 12.3(11)).
 Thus, any such use would be illegal in the generic unit.
 
+One other issue addressed by this AI is the application of 4.9(35) to
+static expressions where the expected type is a universal numeric type or
+where the expression is expected to be of any integer or real type. There
+isn't a clearly specified base range in such cases, and we want to allow
+values of large magnitude in those contexts, even outside the range of
+root_integer. Therefore we revise the rule so that in those cases the
+expression's value is allowed to be arbitrarily large or small.
+
+!corrigendum 4.09(35)
+
+@drepl
+@xbullet<If the expression is not part of a larger static expression,
+then its value shall be in the base range of its expected type. Otherwise,
+the value may be arbitrarily large or small.>
+@dby
+@xbullet<If the expression is not part of a larger static expression and the
+expected type for the expression is required to be a single, specific type,
+then its value shall be in the base range of its expected type. Otherwise,
+the value may be arbitrarily large or small.>
+
 !corrigendum 4.09(37)
 
-@dinsa
+@drepl
 The last two restrictions above do not apply if the expected type is a
 descendant of a formal scalar type (or a corresponding actual type in an
 instance).
+@dby
+The last restriction above does not apply if the expected type is a
+descendant of a formal scalar type (or a corresponding actual type in an
+instance).
+
+The above restrictions apply also in the private part of an instance
+of a generic unit.
+
+!corrigendum 4.09(38)
+
+@dinsa
+For a real static expression that is not part of a larger static expression,
+and whose expected type is not a descendant of a formal scalar type, the
+implementation shall round or truncate the value (according to the
+Machine_Rounds attribute of the expected type) to the nearest machine number of
+the expected type; if the value is exactly half-way between two machine
+numbers, any rounding shall be performed away from zero. If the expected type
+is a descendant of a formal scalar type, no special rounding or truncating is
+required -- normal accuracy rules apply (see Annex G).
 @dinst
-If a static expression appears in an instance body and the expression is
-non-static in the generic body, then none of the legality rules for static
-expressions apply to the expression in the instance.
+If a static expression appears in the body of an instance of a generic unit
+and the expression is nonstatic in the corresponding generic body, then the
+above accuracy requirement does not apply.
+
+!corrigendum 12.04(10)
+
+@drepl
+In an instance, a @fa<formal_object_declaration> of mode @b<in> declares a new
+stand-alone constant object whose initialization expression is the actual,
+whereas a @fa<formal_object_declaration> of mode @b<in out> declares a view
+whose properties are identical to those of the actual.
+@dby
+In an instance, a @fa<formal_object_declaration> of mode @b<in> is a
+@i<full constant declaration> and declares a new stand-alone constant object
+whose initialization expression is the actual, whereas a
+@fa<formal_object_declaration> of mode @b<in out> declares a view
+whose properties are identical to those of the actual.
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent