CVS difference for ais/ai-00178.txt

--- ais/ai-00178.txt	2003/01/24 04:14:27	1.3
+++ ais/ai-00178.txt	2003/03/04 04:56:21	1.4
@@ -1,5 +1,6 @@
-!standard 09.05.01 (18)                               03-01-10  AI95-00178/02
+!standard 09.05.01 (18)                               03-02-20  AI95-00178/03
 !class ramification 03-01-10
+!status ARG Approved 8-0-0  03-02-09
 !status work item 99-09-18
 !status received 97-03-19
 !priority Low
@@ -45,10 +46,10 @@
 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
+Could a more narrow interpretation 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.).
 
@@ -76,7 +77,7 @@
 
 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
+Clearly, for all of the reasons mentioned previously, that would be 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.
@@ -106,17 +107,6 @@
 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
 
 !section 9.5.1(18)
@@ -144,5 +134,21 @@
 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?
+
+****************************************************************
+
+From: Randy Brukardt
+
+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.
+
+At the 18th Meeting of the ARG, we decided not to do this, as the wording
+is insufficiently broken.
 
 ****************************************************************