CVS difference for ais/ai-00178.txt

--- ais/ai-00178.txt	1999/09/23 18:39:39	1.2
+++ ais/ai-00178.txt	2003/01/24 04:14:27	1.3
@@ -1,5 +1,5 @@
-!standard 09.05.01 (18)                               99-09-18  AI95-00178/01
-!class binding interpretation 97-03-19
+!standard 09.05.01 (18)                               03-01-10  AI95-00178/02
+!class ramification 03-01-10
 !status work item 99-09-18
 !status received 97-03-19
 !priority Low
@@ -8,91 +8,114 @@
 
 !summary
 
-All subprograms declared in the packages Ada.Stream_IO, Ada.Text_IO or
-Ada.Text_IO.Text_Streams are potentially blocking.
+All subprograms that manipulate files (implicitly or explicitly) defined in
+language-defined input-output packages are potentially blocking.
 
-All subprograms declared in an instantiation of the generic packages
-Ada.Direct_IO or Ada.Sequential_IO are potentially blocking.
+Any subprogram that has a file parameter or result or operates on a default
+file is considered to manipulate a file.
 
-Consider the subprograms declared in an instantiation or a nongeneric equivalent
-of the generic packages Ada.Text_IO.Complex_IO,
-Ada.Wide_Text_IO.Wide_Complex_IO, or of the generic packages declared in the
-specification of Ada.Text_IO and Ada.Wide_Text_IO.  They are potentially
-blocking unless their declaration starts with either:
-
-        procedure Put (To : out String; ...
-
-or:
-
-        procedure Get (From : in String; ...
-
-The subprograms declared in an instantiation of Ada.Storage_IO are not
-potentially blocking.
-
 !question
 
 9.5.1(18) states that "the subprograms of the language-defined input-output
 packages that manipulate files (implicitly or explicitly) are potentially
-blocking."  It is not clear what this means.
+blocking." It is not clear what this means.
 
-1.  Is "that manipulate files" meant to modify "subprograms" (in which case
+1. Is "that manipulate files" meant to modify "subprograms" (in which case
 the versions of Put that write to strings are excluded) or "packages" (in
 which case these versions of Put might be included, but see #2).
+("Subprograms".)
 
 2. Is a subprogram provided by an instance of a generic package nested in
-Ada.Text_IO considered a subprogram "of" Ada.Text_IO?
+Ada.Text_IO considered a subprogram "of" Ada.Text_IO? (Yes.)
 
 3. Which subprograms are considered to "manipulate files"? Is any
 subprogram with a File_Type parameter, plus any counterpart that operates
 in the same way on a default file, considered to "manuipulate files", or is
 manipulation of files restricted to subprograms that perform what A.8.2
-calls "File Management"?  Indeed, are the file-management functions that
+calls "File Management"? Indeed, are the file-management functions that
 query properties of an internal file (Mode, Name, Form, Is_Open) considered
-to manipulate files?
-
-!recommendation
-
-(See summary.)
+to manipulate files? (Yes.)
 
-!wording
+!response
 
-(See summary.)
-
-!discussion
-
-It is clear that any subprogram that calls an operating system service to read
-or modify an external file has to be considered potentially blocking, since it
-can take an arbitrary amount of time to complete.  This includes the file
-management operations (Create, Open, Close, etc.) as well as the operation that
-read or modify the contents of the file (Read, Write, Flush, etc.).  In practice
-it is likely that some buffering will take place, and therefore not all
-read/write operations will call a system service, but we have to assume the
-worst.
-
-There are operations, like Form, Line_Length, etc., which probably don't need to
-call any system service, but can merely be implemented by retrieving information
-from some data structure associated with the File_Type object.  However, for an
-implementation that would support concurrent access to internal files, accessing
-this data structure would require some synchronization (e.g., to ensure that any
-file management operation in progress has completed), and the synchronization
-itself would be potentially blocking (for instance it could be implemented by
-entry calls).
-
-We don't want to prevent an implementation from supporting concurrent access to
-a given file object (although we don't require it; see RM95 A(3)).  Moreover,
-the capability of calling Form or Line_Length inside a protected operation
-doesn't seem too useful.  That why we state that all operations that involve
-(explicitly or implicitly) File_Type objects are potentially blocking.
-
-The Get and Put procedures that read from/write to a string are different in the
-sense that they don't involve any File_Type object.  In fact, they have no
-relationship whatsoever with I/Os: they are just string manipulation operations.
-So it seems that they should behave just like the operations from the string
-packages (Ada.Strings.Fixed and the like), and therefore they should not be
-potentially blocking.
+In order to answer the first question, we'll need to first think about the
+meaning of "manipulate files" (and thus answer the third question).
 
-Similarly, the operations of Ada.Storage_IO only affect in-memory byte strings,
-so they should not be potentially blocking.
+The wording of 9.5.1(18) just says "manipulate files" and does not put any
+restrictions on the subprograms covered. Thus a broad interpretation seems
+intended.
+
+Could a more narrow intpretation been intended? It is clear that any subprogram
+that might call an operating system service to read or modify an external file
+has to be considered potentially blocking, since such a call can take an
+arbitrary amount of time to complete. This includes the file management
+operations (Create, Open, Close, etc.) as well as the operation that read or
+modify the contents of the file (Read, Write, Flush, etc.).
+
+There are operations, like Form, Line_Length, etc., which probably don't need
+to call any system service, but can merely be implemented by retrieving
+information from some data structure associated with the File_Type object.
+However, for an implementation that would support concurrent access to internal
+files, accessing this data structure would require some synchronization (e.g.,
+to ensure that any file management operation in progress has completed), and
+the synchronization itself would be potentially blocking (for instance it could
+be implemented by entry calls). We don't want to prevent an implementation from
+supporting concurrent access to a given file object (although we don't require
+it; see RM95 A(3)).
+
+Thus, it seems that any subprogram with a File_Type parameter and any
+subprogram that operates implicitly on a default file should be potentially
+blocking. That matches the broad, simple wording of the paragraph, and thus
+we conclude that that is the meaning and intent of 9.5.1(18).
+
+Having answered the third question, let's turn to the second question.
+Clearly, the wording of 9.5.1(18) covers the generic packages nested in
+Ada.Text_IO, as well as Ada.Sequential_IO and Ada.Direct_IO. These clearly
+are "language-defined input-output packages"; the fact that they are generic
+or nested or both doesn't change that status.
+
+Are instances of those packages covered? If they are not, we would have
+some file manipulation subprograms that were not covered by this paragraph.
+Clearly, for all of the reasons mentioned previously, that would wrong and
+contrary to the intent of the paragraph. Thus, we conclude that such instances
+are covered by this paragraph and thus may contain potentially blocking
+subprograms.
+
+Finally, let's turn to the first question.
+The packages Ada.Text_IO, Ada.Wide_Text_IO, Ada.Sequential_IO, Ada.Direct_IO,
+Ada.Streams.Stream_IO, and the nested and child packages of them, all contain
+subprograms that manipulate files. All subprograms that manipulate files are
+included by either reading of 9.5.1(18). For all of these packages, the only
+subprograms that do not have either a File_Type parameter or result, and
+do not manipulate a default file, are the Get and Put procedures that read
+from/write to a string defined in the nested packages of Ada.Text_IO (and
+Ada.Wide_Text_IO).
+
+Thus, this question boils down to whether those Get and Put procedures are
+potentially blocking. These routines really have no relationship whatsoever
+with IO: they are just string manipulation operations. There is no implementation
+reason that they need to be potentially blocking. Moreover, it would be
+preferable if they were consistent with the other string operations defined
+by the standard (the operations in the string packages Ada.Strings.Fixed and
+the like).
+
+Therefore, we adopt the less restrictive interpretation.
+
+We have not previously discussed Ada.Storage_IO. While its name suggests that
+it may be included under this rule, it in fact contains no subprograms that
+manipulate files (it only manipulates in-memory byte strings). Therefore, its
+operations are not potentially blocking.
+
+[Editor's note: I'd prefer to clarify the wording of 9.5.1(18) as in the
+summary:
+"All subprograms that manipulate files (implicitly or explicitly) defined in
+language-defined input-output packages are potentially blocking. Any subprogram
+that has a file parameter or result or operates on a default file is
+considered to manipulate a file."
+This is not strictly necessary, but would avoid confusion, particularly about
+the status of the subprograms in the nested Text_IO packages that take strings.
+But it would be weird to modify normative wording in a ramification, so I
+didn't do it in this version.]
 
 !appendix