CVS difference for ais/ai-00195.txt
--- ais/ai-00195.txt 2000/07/08 02:40:52 1.12
+++ ais/ai-00195.txt 2000/12/06 21:46:43 1.13
@@ -1,4 +1,4 @@
-!standard 13.13.1 (00) 00-07-07 AI95-00195/06
+!standard 13.13.1 (00) 00-11-14 AI95-00195/07
!class binding interpretation 98-03-27
!status work item 98-04-04
!status received 98-03-27
@@ -49,14 +49,32 @@
9 - The number of calls performed by the predefined implementation of the
stream-oriented attributes to the Read and Write operations of the stream
type is unspecified (an implementation may take advantage of this rule to
-perform internal buffering). However, all the calls to Read and Write needed
+perform internal buffering). However, all the calls to Read and Write needed
to implement a top-level invocation of a stream-oriented attribute must take
place before this top-level invocation returns.
-10 - The predefined stream-oriented attributes for a scalar type shall only
-read or write the minimum number of stream elements required by the first
-subtype of the type. Constraint_Error is raised if such an attribute is
-passed (or would return) a value outside the range of the first subtype.
+10 - By default, the predefined stream-oriented attributes for a scalar type
+shall only read or write the minimum number of stream elements required by
+the first subtype of the type, rounded up to the nearest
+factor or multiple of the word size that is also a multiple of
+the stream element size. The number of bits occupied in a stream
+by items of a type are given by the value of the specifiable
+type-related attribute Stream_Size. Hence, the number of stream elements
+required per item of type T is:
+ T'Stream_Size / Ada.Streams.Stream_Element'Size.
+If specified, T'Stream_Size shall be a multiple of Stream_Element'Size.
+The recommended level of support for the Stream_Size attribute
+is: A Stream_Size clause should be supported for a type T if the
+specified Stream_Size is a multiple of Stream_Element'Size and is
+no less than the size of the first subtype of T.
+Constraint_Error is raised by the predefined Write attribute if
+the value of the item is outside the range of values representable
+using Stream_Size bits (the range is unsigned if necessary to cover
+all values of the first subtype or if the type has no negative integer
+codes; otherwise the range is signed).
@@ -185,19 +203,7 @@
Read above were moved to the visible part of P, a reference to P.T'Read would
still be illegal (but a reference to P.Read wouldn't).
-For limited types, this rule creates another problem: RM95 13.1(9) states
-that a representation item shall only appear after the type has been
-completely defined. This would require the attribute_definition_clause to
-appear in the private part, thus being invisible to clients of the package.
-RM95 13.1(9) is in fact unnecessary for stream attributes: to quote AI-00137
-(which states that RM95 13.1(10) doesn't apply to stream-oriented attributes)
-"the stream-oriented attributes, although they are formally defined to be
-"representation attributes", do not actually affect the representation of the
-type." Therefore, we must amend RM95 13.1(9) so that it doesn't apply to the
3 - The rules given in 13.13.2(36) (as amended by 8652/0040 [AI-00108]),
say that "All nonlimited types have default implementations for these
operations." However, many limited types also have default implementations
@@ -339,21 +345,21 @@
extra negative value," as explained in RM95 3.5.4(9).
Based on this rule (and assuming typical hardware), an implementation might
-choose an 8-, 16-, 32- or 64-bit base subtype for T.
+choose an 8-, 16-, 32- or 64-bit base type for T.
RM95 13.13.2(17) advise the implementation to "use the smaller number of
stream elements needed to represent all values in the base range of the scalar
type" when reading or writing values of type T.
Clearly this is a portability issue: if two implementation use (as is typical)
-8-bit stream elements, but have different rules for selecting base subtypes, the
+8-bit stream elements, but have different rules for selecting base types, the
number of elements read to or written from a stream will differ. This makes
-it very hard to write stream operations that comply with an externally
+it very hard to write stream operations that comply with an externally defined
In the above case, it would seem reasonable to read or write only the minimum
number of stream elements necessary to represent the range 1 .. 10. This
-would remove the dependency on the base subtype selection, and make it easier to
+would remove the dependency on the base type selection, and make it easier to
write portable stream operations. (There is still the possibility that
different implementations would choose different sizes for stream elements,
but that doesn't seem to happen in practice on typical hardware.)
Questions? Ask the ACAA Technical Agent