Version 1.2 of ai05s/ai05-0194-1.txt

Unformatted version of ai05s/ai05-0194-1.txt version 1.2
Other versions for file ai05s/ai05-0194-1.txt

!standard 13.13.2(1.2/2)          09-12-08 AI05-0194-1/02
!class binding interpretation 09-12-08
!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?
!recommendation
(See summary.)
!wording
Replace the first sentence of 13.13.2(1.2/2) by:
Denotes the number of bits read from or written to a stream by the default implementations of S'Read and S'Write.
Add after 13.13.2(1.a/2):
AARM ramification:
The value of S'Stream_Size is unaffected by the presence or absence of any attribute definition clauses specifying the Read or Write attributes of any ancestor of S. S'Stream_Size is defined in terms of the behavior of the default implementations of S'Read and S'Write even if those default implementations are overridden.
!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. We change the definition of S'Stream_Size in order to avoid any confusion, but there is no change in the intended semantics.
The original wording of 13.13.2(1.6/2) 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.
!corrigendum 13.13.2(1.2/2)
Replace the paragraph:
Denotes the number of bits occupied in a stream by items of subtype S. Hence, the number of stream elements required per item of elementary type T is:
by:
Denotes the number of bits read from or written to a stream by the default implementations of S'Read and S'Write. Hence, the number of stream elements required per item of elementary type T is:
!ACATS Test
None needed, there is no intended change of semantics.
!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...

****************************************************************

From: Steve Baird
Sent: Tuesday, December 8, 2009  2:23 PM

I've got an action item to take a stab at clarifying wording for AI05-0194, so
here goes.

13.13.2(1.2/2) currently says
     Denotes the number of bits occupied in a stream by items of
     subtype S.

Replace this with:
     Denotes the number of bits read from or written to a stream by the
     default implementations of S'Read and S'Write.

   AARM note:
     The value of S'Stream_Size is unaffected by the presence or absence
     of any attribute definition clauses specifying the Read or Write
     attributes of any ancestor of S. S'Stream_Size
     is defined in terms of the behavior of the default implementations
     of S'Read and S'Write even if those default implementations are
     overridden.

Randy points out that accepting this change would mean that the !class for the
AI then needs to be changed from "ramification" to "binding interpretation" and
that consequently the "!response" section becomes a "!recommendation" section.

****************************************************************

From: Tucker Taft
Sent: Tuesday, December 8, 2009  2:46 PM

This looks like a helpful clarification.  I am surprised it needs to be
classified as a binding interpretation, since it isn't changing the intent, it
is just clarifying the wording.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, December 8, 2009  3:00 PM

We classify any change to the normative wording as a Binding Interpretation.
Only changes to notes (esp. AARM notes), examples, etc. can be ramifications.
That's because any change to the normative wording can have consequences for
implementations. In this case, if anyone misintrepreted 'Stream_Size (one
possibility would be to assume that it always means the binary size of the
subtype, even when some other meaning of the default stream attributes), they
might feel compelled to change the values of the attribute. Not very likely,
perhaps, but still possible. (Also, by doing so we don't need to argue about
whether the change is "clarifying" or "significant". Which sounds like a waste
of time, but yet one that would happen given our group dynamics.)

****************************************************************

Questions? Ask the ACAA Technical Agent