!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) @drepl @xindent is:> @dby @xindent 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.) **************************************************************** From: Tucker Taft Sent: Tuesday, December 8, 2009 3:49 PM OK! BI it is. ****************************************************************