Version 1.1 of ai05s/ai05-0194-1.txt
!standard 13.13.2(1.6/2) 09-11-03 AI05-0194-1/01
!class ramification 09-11-03
!status work item 09-11-03
!status received 09-07-23
!priority Low
!difficulty Easy
!qualifier Omission
!subject The default value of S'Stream_Size
!summary
The default value of S'Stream_Size is not affected by the definition of S'Read
or S'Write. In particular, the value does change if S'Read or S'Write is
overridden.
!question
What is the value of S'Stream_Size if it is not user-specified, while S'Write
has been user-specified?
!response
(See summary.)
!wording
Add an AARM Note after 13.13.2(1.6/2.c):
AARM Ramification: The default value of the Stream_Size attribute depends on how
the implementation converts values into stream elements for the default
implementation of Read and Write for elementary types. It does not necessarily
correspond directly to a conversion of the binary representation to a number of
stream elements (although that is the most likely meaning). The default value of
the Stream_Size attribute does not depend on the implementation of any
user-defined stream attributes.
!discussion
Any interpretation other than the one given in the proposed AARM note fails
"Robert's rule", as any other interpretation quickly leads to nonsense.
The original wording was carefully worded in terms of the "stream elements
required"; it very carefully avoids any mention of "binary representation"
or "memory representation" as some seem to think is intended. The "stream
elements required" clearly depend on how the memory representation is
converted to stream elements, but there is no assumption that that conversion
is an identity function.
In addition, 13.13.2(9/2) requires the number of stream elements read by
the default implementation of S'Read to be that of the value of S'Stream_Size.
There is no wiggle room here: an implementation that does something else
is wrong.
Note that an implementation that supports a non-binary representation for
streaming does not have to change the value of Stream_Size accordingly. It could
simply say that the attributes are automatically user-defined to use the
non-binary representation. (In that case, Stream_Size would not need to be
used in the attribute.) Alternatively, it could adjust the default value of
Stream_Size to reflect the non-binary representation.
!ACATS Test
None needed.
!appendix
From: Jean-Pierre Rosen
Sent: Thursday, July 23, 2009 3:41 PM
While looking at this section, it made me think of a related question: what is
the value of S'Stream_Size if it is not user-specified, while S'Write has been
user-specified? 13.13.2(1.6/2) does not say that it corresponds to the default
implementation. It seems that S'Stream_Size is intended to be used to specify a
size while using the default implementation of S'Write, but that the other way
round is not defined. Is it worth another AI?
****************************************************************
From: Randy Brukardt
Sent: Thursday, October 15, 2009 8:07 PM
I don't see any problem. 13.13.2(1.6/2) says nothing about Read or Write. The
"minimum number of stream elements required by the first subtype" is
well-defined no matter how those attributes are defined. Stream_Size is of
course used in the default Read and Write attributes, but obviously does not
have any effect on user-defined attributes. Moreover, Stream_Size could be
useful in contexts other than the attributes (such as determining the
appropriate size for an Unchecked_Conversion to stream elements), so I think
this is a good thing.
I suppose one could have a user note saying that "Stream_Size is meaningless for
user-defined Read and Write attributes", but that seems obvious and clearly
follows from the definition. It seems more like something to mention in
textbooks and tutorials to me. So I don't think we need to do anything (and
surely not an AI).
****************************************************************
From: Jean-Pierre Rosen
Sent: Sunday, October 18, 2009 1:24 AM
I see your point, but I don't think it is so well defined. You are assuming that
the stream representation is the same as the memory representation, but this is
of course not required.
Take for example Gnat with annex E: it uses XDF for its default stream
representation. What is the value of S'Stream_Size? Is it based on the binary
representation (in which case the number of bytes written by the default S'Write
is /not/ S'Stream_Size), or on the actual S'Write (in which case my question
makes sense) ?
****************************************************************
From: Randy Brukardt
Sent: Monday, October 19, 2009 9:13 PM
> I see your point, but I don't think it is so well defined.
> You are assuming that the stream representation is the same as the
> memory representation, but this is of course not required.
No, I'm not assuming that. I'm assuming that the default implementation of Read
and Write does something well-defined. 'Stream_Size is obviously related to
those implementations, never anything user-defined.
> Take for example Gnat with annex E: it uses XDF for its default stream
> representation. What is the value of S'Stream_Size? Is it based on
> the binary representation (in which case the number of bytes written
> by the default S'Write is /not/ S'Stream_Size), or on the actual
> S'Write (in which case my question makes sense) ?
That depends on whether GNAT is changing the default 'Read and 'Write to use XDF
(in which case, 'Stream_Size argubly should also change to reflect that), or
whether GNAT is treating the XDF versions as being "automagically" user-defined,
in which case 'Stream_Size doesn't change. (The latter interpretation allows
Stream_Size to be independent of implementation if some implementation wishes.)
I think I would prefer the latter, but either makes sense. But under no
circumstances does 'Stream_Size have any dependence on whether 'Read/'Write is
user-defined.
****************************************************************
From: Jean-Pierre Rosen
Sent: Tuesday, October 20, 2009 12:33 AM
Fine, but "Denotes the number of bits occupied in a stream by items of subtype
S" says nothing about the way the item is transformed into stream elements. You
seem to take it for granted that it is the binary representation and/or the
default S'write, but I can't find any wording to support that.
****************************************************************
From: Tucker Taft
Sent: Tuesday, October 20, 2009 10:00 AM
In rereading this section, I agree it should be made clearer that we are talking
about the binary representation of the default implementation of the 'Read and
'Write attributes. The way it is written now, it could be misinterpreted in
several ways.
****************************************************************
From: Randy Brukardt
Sent: Tuesday, October 20, 2009 12:41 PM
I guess I don't see that: Robert's rule applies, and there isn't any other
interpretation that even remotely makes sense. But I guess I'm in the minority,
and clearly we need more work on our agenda, :-) so an AI will have to be
opened.
Tucker, how would you suggest changing the wording to make it clear that
Stream_Size doesn't change? I don't think "binary representation" really has
anything to do with it, as it matters how the implementation represents the
default stream attributes (that's implementation-defined, of course, it doesn't
have to be binary). If it always uses XDF, for instance, I would think that
Stream_Size ought to reflect that. That seems like it has to be the case, or
else the default stream attributes would not do the right thing for the default
Stream_Size: "Read reads the number of stream elements implied by the
Stream_Size for T".
Let me repeat that: 13.13.2(9/2) requires that the default Stream_Size for T be
the number of stream elements read/written by the default stream attribute for
T. I don't see any wiggle room there; it clearly depends on the default stream
representation.
And I don't see any justification for saying that if a stream attribute for T is
overridden, the default Stream_Size might change -- it's definition only depends
on the default stream attribute and there is no indication that it might change.
I suppose you can construct a tortuous argument that if you aren't using the
default stream attribute, there is no constraint on the value -- but that would
be different than the way all of the other representation attributes work. I
don't see any reason that this one should be different.
So I still don't see anything worth changing here, but if a Ramification AI will
make someone feel better, I guess I'll write it up...
****************************************************************
Questions? Ask the ACAA Technical Agent