CVS difference for ais/ai-00085.txt

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

--- ais/ai-00085.txt	2001/01/23 22:23:30	1.5
+++ ais/ai-00085.txt	2002/01/03 01:46:06	1.6
@@ -1,4 +1,4 @@
-!standard A.8.2    (16)                               98-04-04  AI95-00085/05
+!standard A.8.2    (16)                               02-01-02  AI95-00085/06
 !standard A.12.1(33)
 !class confirmation 95-08-19
 !status work item 98-10-09
@@ -9,7 +9,7 @@
 !difficulty Hard
 !subject Append_File, Reset and positioning
 
-!summary 98-04-04
+!summary
 
 A call to Reset without the Mode parameter is equivalent to a call
 to Reset with the current mode of the file.
@@ -25,32 +25,32 @@
 The procedure Stream_IO.Set_Mode sets the mode of the file, it doesn't
 necessarily change it.
 
-!question 98-04-04
+!question
 
 1. Are the following two calls equivalent, even if F is opened in
-   Append_File mode? (yes)
+   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
+   "from the beginning of the file". 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)
+   of the external file? (Yes.)
 
 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.)
+   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
+4. 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)
+   mode of the file? (No.)
 
 
-!response 98-04-04
+!response
 
-1. RM95 A.8.2(16) states that: "if a Mode parameter is supplied,
+1. 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
@@ -59,21 +59,21 @@
 
 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
+external file. This is explicitly stated in 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
+2. When 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)).
+end of the external file (despite 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
+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
+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.
 
@@ -82,27 +82,38 @@
 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
+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
+for open). 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."
 
+The standard makes no requirements about whether a particular file supports
+positioning or not. Thus, An implementation does not have to support
+positioning on any files at all if it likes. It may use any rule that makes
+sense for the target system. In particular, it is acceptable for a file to not
+support positioning if the mode is Append_File, and for the same external file
+to support positioning if the mode is Out_File.
+
 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.
+that are not provided by the underlying OS. Moreover, since there is no
+requirement to support positioning on any stream files, a truly portable
+program would have to avoid positioning of stream files in any mode. Thus,
+allowing implementations to use O_APPEND does not impose any further
+portability penalty.
 
-4. RM95 A.12.1(35) should say that "the procedure Set Mode sets the mode
+4. 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
+!appendix
 
 !section A.7(02)
 !subject Questions about Append_File mode

Questions? Ask the ACAA Technical Agent