CVS difference for ais/ai-00137.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00137.txt

--- ais/ai-00137.txt	1998/09/30 00:17:24	1.1
+++ ais/ai-00137.txt	1999/07/29 00:51:02	1.2
@@ -1,5 +1,6 @@
-!standard 13.01    (10)                               96-07-23  AI95-00137/01
+!standard 13.01    (10)                               99-07-28  AI95-00137/02
 !class binding interpretation 96-05-07
+!status Corrigendum 2000 99-07-28
 !status WG9 approved 96-12-07
 !status ARG approved 6-0-2  96-06-17
 !status work item 96-05-08
@@ -8,7 +9,7 @@
 !difficulty Medium
 !subject Attribute definition clause for Stream Attributes
 
-!summary 96-05-08
+!summary
 
 13.1(10) says:
 
@@ -19,7 +20,7 @@
 This rule does not apply to an attribute_definition_clause for one of
 the stream-oriented attributes Read, Write, Input, and Output.
 
-!question 96-05-08
+!question
 
 13.1(10) seems to forbid the following example:
 
@@ -34,14 +35,16 @@
      for NT'Write use Attribute_Write; -- Illegal?  (No.)
    end Attr_Rep;
 
-!recommendation 96-05-08
+!recommendation
 
 (See summary.)
 
-!wording 96-05-08
+!wording
 
-!discussion 96-05-08
+(See corrigendum.)
 
+!discussion
+
 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 "representation
@@ -49,16 +52,45 @@
 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.
+
+!corrigendum 13.01(10)
+
+@drepl
+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.
+@dby
+For an untagged derived type, no type-related representation items, other
+than the stream-oriented attributes Read, Write, Input, and Output, are
+allowed if the parent type is a by-reference type, or has any user-defined
+primitive subprograms.
+
+!corrigendum 13.01(11)
+
+@drepl
+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.
+@dby
+Representation aspects of a generic formal parameter are the same as those
+of the actual. A type-related representation item, other than the
+stream-oriented attributes Read, Write, Input, and Output, is not allowed
+for a descendant of a generic formal untagged type.
+
+!ACATS test
 
-!appendix 96-06-06
+Create a C-Test to verify that Read/Write attributes can be defined
+on derived non-tagged types.
 
+!appendix
+
 !section 13.1(10)
 !subject Attribute definition clause for Stream Attributes
 !reference RM95-13.1(10)
 !reference RM95-13.1(11)
 !reference RM95-13.13.2(36)
 !from Anthony Gargaro 96-04-28
-!keywords 
+!keywords
 !reference 96-5519.a Anthony Gargaro  96-4-28>>
 !discussion stream attributes, representation items
 
@@ -83,7 +115,7 @@
             Stream : access Root_Stream_Type'Class;
             Item   : in NT) is
   begin
-    -- Save type information for dispatching Write and then call 
+    -- Save type information for dispatching Write and then call
     T'Write(Stream, T(Item));
   end Attribute_Write;
 end Attr_Rep;
@@ -169,7 +201,6 @@
 
 - Bob
 
-
 ****************************************************************
 
 !section 13.1(10)
@@ -194,18 +225,17 @@
 >Right.  Another workaround is to simply make the thing a tagged type,
 >since 13.1(11) applies only to untagged types.
 
-In the context of the application where this issue was raised both of these 
-options were considered. Unfortunately, neither seems satisfactory since the 
-useability of the abstraction which is presented to the programmer is 
-compromised. This is because the idiom requires the incremental composition of 
-types to allow arbitrary user-defined types to be associated with "architecture 
+In the context of the application where this issue was raised both of these
+options were considered. Unfortunately, neither seems satisfactory since the
+useability of the abstraction which is presented to the programmer is
+compromised. This is because the idiom requires the incremental composition of
+types to allow arbitrary user-defined types to be associated with "architecture
 neutral" stream attributes.
 
-In the case of wrapping the type (which is used at the moment), there is a 
-useability penalty. The programmer must be aware of the wrapper name when 
-referencing subcomponents of the type and this may become onerous if the 
+In the case of wrapping the type (which is used at the moment), there is a
+useability penalty. The programmer must be aware of the wrapper name when
+referencing subcomponents of the type and this may become onerous if the
 composite type contains other composite types.
-
 
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent