CVS difference for ais/ai-00085.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00085.txt

--- ais/ai-00085.txt	1998/09/30 00:17:14	1.1
+++ ais/ai-00085.txt	1998/09/30 22:22:11	1.2
@@ -1,53 +1,105 @@
-!standard A.8.2    (16)                               96-11-18  AI95-00085/03
-!standard A.12.1(28)
-!standard A.12.1(35)
+!standard A.8.2    (16)                               98-04-04  AI95-00085/05
+!standard A.12.1(33)
 !class confirmation 95-08-19
+!status ARG approved (subject to editorial review) 12-0-0  98-04-03
 !status work item 95-11-01
 !status received 95-08-19
 !priority High
 !difficulty Hard
-!subject Questions about Append_File mode
+!subject Append_File, Reset and positioning
 
-!summary 96-11-18
+!summary 98-04-04
 
-???TBD
+A call to Reset without the Mode parameter is equivalent to a call
+to Reset with the current mode of the file.
 
-At the Vermont ARG meeting, it was agreed to answer this AI as for the
-comment from Tucker Taft.  Also, the issues related to Stream_IO will be
-split out into another AI.
-
-!question 95-08-19
-
-
-!recommendation 95-08-19
-
-
-!wording 95-08-19
-
-
-!discussion 95-08-19
-
-I (Bob Duff) am not sure what the right answers are here.  I've
-discussed this with Robert Dewar.
-
-It seems to make sense for Reset with no mode to always use the current
-mode.
-
-Now, where does reset go for a file opened in Append_Mode?  In Unix, if
-you use fopen with mode "a", it is impossible to go back before the
-append point.  Should we allow this behavior?  Require this behavior?
-
-Note that if using mode "a" in Unix is wrong, then it is impossible to
-use Append_Mode to write to a write-only file, which seems unfortunate.
-Imagine a program that is allowed to add lines to a log file, but is not
-supposed to be allowed to read previous log entries.
-
-Note that in Stream_IO, it seems that one can open in Append_Mode, and
-then use Set_Index to set the position before the initial append point.
-
-Are other operating systems different from Unix in this regard?  Should
-we require the unix-like behavior, or disallow it, or allow the OS to
-decide (i.e. implementation dependent)?
+The beginning and end of the file mentioned in the description of
+the semantics of Reset designate the beginning and end of the external
+file.
+
+It is legitimate for an implementation to raise Use_Error on the
+positioning operations of Stream_IO in the circumstances where the
+underlying operating system does not support positioning.
+
+The procedure Stream_IO.Set_Mode sets the mode of the file, it doesn't
+necessarily change it.
+
+!question 98-04-04
+
+1. Are the following two calls equivalent, even if F is opened in
+   Append_File mode? (yes)
+
+      Reset (F, Mode => Mode (F));
+      Reset (F);
+
+2. A call to Reset with mode In_File allows reading to be restarted
+   "from the beginning of the file".  RM95 A.7(2) indicates that
+   the term "file" refers to a file object, not to an external file.
+   Does the phrase "beginning of the file" refer to the beginning
+   of the external file? (the external file)
+
+3. For a Unix implementation that uses the Unix append mode to implement
+   files opened in Append_File mode, what are the possible effects of
+   Set_Index? (do the right thing or raise Use_Error.)
+
+4. RM95 A.12.1(35) says that "the Set_Mode procedure changes the mode of
+   file."  Does that mean that Set_Mode can only be used to "change" the
+   mode of the file? (no)
+
+
+!response 98-04-04
+
+1. RM95 A.8.2(16) states that: "if a Mode parameter is supplied,
+the current mode of the given file is set to the given mode."  This
+paragraph doesn't mention any other effect for the Mode parameter;
+therefore, setting the Mode parameter Mode (F) has essentially no
+effect, and the two calls Reset (File, Mode (File)) and Reset (File)
+are equivalent.
+
+For a file which is opened in Append_File mode, Reset (F) positions
+the file so that writing can be restarted after the last element of the
+external file.  This is explicitly stated in RM95 A.8.2(16), although
+this section uses the word "file" when it should say "external file".
+
+Note that for a Unix implementation, it makes it possible to use the
+Unix append mode, and to implement any of these two calls without closing
+and reopening the file.
+
+2. When RM95 A.8.2(16) talks about the "beginning of the file" or
+"the last element of the file" it is talking about the beginning and
+end of the external file (despite RM95 A.7(2)).
+
+For a file that is Reset to mode In_File, reading restarts at the
+beginning of the external file.   This is supported by the annotation in
+AARM A.10.2(4.a), which indicates that Reset should be similar to closing
+and then reopening.  The internal file essentially disappears between
+closing and reopening, so clearly Reset is resetting based on properties
+of the external file, not of the internal file.
+
+Note that for a Unix implementation which uses the Unix append mode to
+implement files opened in Append_File mode, this means that resetting
+to In_File or Out_File must be implemented by closing and reopening.
+
+3. It is the intent that a Unix implementation can use the Unix append
+mode to implement files opended in Append_File mode.  For a stream
+designating such a file, positioning is effectively impossible because,
+if the O_APPEND bit was set at open time, "the file pointer is set to the
+end of the file prior to each write" (excerpt from the Unix man page
+for open).  RM95 A.12.1(32) makes it clear that such an implementation
+is legitimate, provided that it raises Use_Error on the positioning
+operations: "if positioning is not supported for the given file, then a
+call to Index or Set_Index propagates Use_Error."
+
+Although this compromises portability (different compilers may use
+different implementations, and certainly different OSes may have
+different restrictions), the stress here is on performance: the intent
+is that the file and stream operations should be implemented as a thin
+layer on top of the OS calls, and should not have to simulate services
+that are not provided by the underlying OS.
+
+4. RM95 A.12.1(35) should say that "the procedure Set Mode sets the mode
+of the file."  If the Mode parameter is the current mode of the file,
+then surely the mode of the file is not changed.
 
 !appendix 96-04-04
 

Questions? Ask the ACAA Technical Agent