CVS difference for ai12s/ai12-0320-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0320-1.txt

--- ai12s/ai12-0320-1.txt	2019/03/08 06:57:49	1.2
+++ ai12s/ai12-0320-1.txt	2019/03/09 05:06:10	1.3
@@ -1,4 +1,9 @@
-!standard E.2.1(7/4)                                    19-03-06  AI12-0320-1/01
+!standard 4.10(3.1/5)                                    19-03-08  AI12-0320-1/02
+!standard 4.10(6/5)
+!standard 5.5.3(11/5)
+!standard C.1(2)
+!standard C.3.2(24/3)
+!standard E.2.1(7/4)
 !standard E.2.1(7.1/4)
 !class binding interpretation 19-03-06
 !status Amendment 1-2012 19-03-06
@@ -29,10 +34,50 @@
 ... nor a type with a part that is of a ((task type) or (protected type with 
 entry_declarations)).
 
+Should this be clarified? (Yes.)
 
+(2) Put_Image is defined as (in 4.10(3.1/5)):
 
+procedure S'Put_Image
+   (Arg    : in T;
+    Stream : not null access Ada.Streams.Root_Stream_Type'Class);
+
+Normally, I/O operations (streaming, text io, and so on) put 
+the stream or file parameter first.
+
+Should these parameters be reversed? (Yes.)
+
+(3) 5.5.3(11/5) ends with "This rule is an overloading rule." But this
+seem unnecessary; *every* rule in a Name-Resolution Rules section is
+an overloading rule by definition. Should this be deleted? (Yes.)
+
+(4) 5.5.3(14/5) is a Legality Rule about abstract subprograms. We made an
+effort to put all of the abstract rules into 3.9.3. Should this rule be
+given there? (Yes.)
+
+(5) The requirements in C.1(2) seem too strong. There is a requirement to
+provide implementation-defined attributes to provide access to Ada entities
+for machine code access. However, this seems like overspecification.
+If language-defined attributes (such as Address) are enough to provide
+the needed access, then the requirement seems to require defining unneeded
+things. Moreover, it seems to require defining more than one, so defining
+only a single attribute also seems to fail the requirement. Finally, if an
+implementation uses intrinsic subprograms to provide machine code access,
+which is allowed by this requirement, then access to Ada entities would be
+by parameter passing, which hardly seems to need anything 
+beyond the usual facilities. Should this requirement be reworded? (Yes.)
+
+(6) C.3.2(24/3) says:
+  If the Ceiling_Locking policy (see D.3) is in effect, the implementation 
+  shall document the default ceiling priority assigned to a protected object
+  that contains a protected procedure that specifies either the 
+  Attach_Handler or Interrupt_Handler aspects, but does not specify the 
+  Interrupt_Priority aspect.
 
+As phrased, it seems that there is a documentation requirement only if the 
+ceiling locking policy is in effect. Is that intended? (No.)
 
+
 !recommendation
 
 (1) The original wording makes it clear that the second interpretation is
@@ -40,6 +85,17 @@
 recommendation is to change this into a list of sub-bullets (and we
 can include the following bullet in that rewrite as well).
 
+(2) Put_Image should have parameters in the same order as Write.
+
+(3) Delete the redundant text.
+
+(4) Put the rule into 3.9.3, and leave the existing copy, marked as Redundant.
+
+(5) Work the requirement in terms of providing access and avoid mentioning
+how that might be done.
+
+(6) Reorder this paragraph.
+
 !wording
 
 Replace E.2.1(7/4-7.1/4) with:
@@ -55,9 +111,107 @@
 
 [Editor's note: Put the AARM notes after the appropriate bullet.]
 
+Replace 4.10(3.1/5) with:
+
+procedure S'Put_Image
+   (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+    Arg    : in T);
+
+Replace 4.10(6/5) with:
+
+procedure Scalar_Type'Put_Image
+  (Stream : access Ada.Streams.Root_Stream_Type'Class; Arg : Scalar_Type) is
+begin
+   Wide_Wide_String'Write (Stream, <described below>);
+end Scalar_Type'Put_Image;
+
+Delete "This rule is an overloading rule (see 8.6)." from the end of 5.5.3(11/5).
+
+Add after 3.9.3(7):
+
+If the name or prefix given in an iterator_procedure_call (see 5.5.3) denotes an 
+abstract subprogram, the subprogram shall be a dispatching subprogram.
+
+Mark 5.5.3(14/5) as redundant.
+
+Modify C.1(2):
+
+The implementation shall support machine code insertions (see 13.8) or intrinsic 
+subprograms (see 6.3.1) (or both). {The implementation}[Implementation-defined 
+attributes] shall [be provided to] allow the use of Ada entities as operands {for
+such machine code insertions or intrinsic subprograms}. 
+
+   AARM Discussion: Ada entities could be used as operands in machine code
+   insertions and/or intrinsic subprograms using language-defined attributes 
+   (such as address), implementation-defined attributes, or could be directly 
+   allowed.
+
+Modify C.3.2(24/3):
 
+{The implementation shall document, if}[If] the Ceiling_Locking policy (see D.3) 
+is in effect, [the implementation shall document ]the default ceiling priority 
+assigned to a protected object that contains a protected procedure that specifies 
+either the Attach_Handler or Interrupt_Handler aspects, but does not specify the 
+Interrupt_Priority aspect.
+
 !discussion
 
+For (2), the closest existing routine is S'Write, and the specification should be
+similar. Otherwise, remembering the order of parameters would quickly become 
+maddening.
+
+For (3), it is particularly weird that the third rule out of four makes this
+statement, when it equally applies to all four rules.
+
+!corrigendum 3.9.3(7)
+
+@dinsa
+A call on an abstract subprogram shall be a dispatching call; [nondispatching 
+calls to an abstract subprogram are not allowed.] 
+@dinst
+If the @fa<name> or @fa<prefix> given in an @fa<iterator_procedure_call> (see 
+5.5.3) denotes an abstract subprogram, the subprogram shall be a dispatching 
+subprogram.
+
+!corrigendum 4.10(0)
+
+@dinsc
+This is a new clause, so just force a conflict; the change is found in the
+conflict file.
+
+!corrigendum 5.5.3(0)
+
+@dinsc
+This is a new clause, so just force a conflict; the change is found in the
+conflict file.
+
+!corrigendum C.1(2)
+
+@drepl
+The implementation shall support machine code insertions (see 13.8) or 
+intrinsic subprograms (see 6.3.1) (or both). Implementation-defined 
+attributes shall be provided to allow the use of Ada entities as operands. 
+@dby
+The implementation shall support machine code insertions (see 13.8) or 
+intrinsic subprograms (see 6.3.1) (or both). The implementation shall 
+allow the use of Ada entities as operands for
+such machine code insertions or intrinsic subprograms. 
+
+!corrigendum C.3.2(24/3)
+
+@drepl
+If the Ceiling_Locking policy (see D.3) 
+is in effect, the implementation shall document the default ceiling priority 
+assigned to a protected object that contains a protected procedure that specifies 
+either the Attach_Handler or Interrupt_Handler aspects, but does not specify the 
+Interrupt_Priority aspect.
+@dby
+The implementation shall document, if the Ceiling_Locking policy (see D.3) 
+is in effect, the default ceiling priority 
+assigned to a protected object that contains a protected procedure that specifies 
+either the Attach_Handler or Interrupt_Handler aspects, but does not specify the 
+Interrupt_Priority aspect.
+
 !corrigendum E.2.1(7/4)
 
 @drepl
@@ -94,6 +248,7 @@
 
 !ACATS test
 
+No ACATS tests should be needed, all of these are mainly wording improvements.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent