Version 1.1 of ais/ai-00085.txt

Unformatted version of ais/ai-00085.txt version 1.1
Other versions for file ais/ai-00085.txt

!standard A.8.2 (16)          96-11-18 AI95-00085/03
!standard A.12.1(28)
!standard A.12.1(35)
!class confirmation 95-08-19
!status work item 95-11-01
!status received 95-08-19
!priority High
!difficulty Hard
!subject Questions about Append_File mode
!summary 96-11-18
???TBD
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)?
!appendix

!section A.7(02)
!subject Questions about Append_File mode
!reference RM95-A.7(2)
!reference RM95-A.8.2(15,16)
!reference AARM95-A.10.2(4.a)
!from Keith Thompson 95-08-09
!reference as: 95-5253.a Keith Thompson 95-8-9>>
!discussion

Some aspects of Append_File mode seem unclear.  For example:

1. Reset with an explicit Mode => Append_File (for a text or sequential
   file) causes writing to continue at the end of the file, yes?
   Assume F is a (text or sequential) file whose current mode is
   Append_File.  Are the following two calls equivalent?

      Reset(F, Mode => Append_File);
      Reset(F);

   More generally, are these always equivalent?

      Reset(F, Mode => Mode(F));
      Reset(F);

   I believe they should be, but I've been unable to prove it from the
   RM or AARM.

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?

   In particular, what is the effect of the following code fragment,
   assuming all operations are successful?

      declare
         package Int_IO is new Ada.Sequential_IO(Integer);
         F: Int_IO.File_Type;
         File_Name: constant String := "foo.dat";
      begin
         Int_IO.Create(F, File_Name);
         for I in 1 .. 3 loop
            Int_IO.Write(F, I);
         end loop;
         Int_IO.Close(F);
         --
         -- foo.dat now contains (1, 2, 3)
         --
         Int_IO.Open(F, Mode => Int_IO.Append_File, Name => File_Name);
         for I in 4 .. 6 loop
            Int_IO.Write(F, I);
         end loop;
         --
         -- foo.dat now contains (1, 2, 3, 4, 5, 6),
         -- but where is the "beginning of the file"?
         --
         Int_IO.Reset(F, Mode => Int_IO.Out_File);
         Int_IO.Write(F, 999);
         Int_IO.Close(F);
      end;

   If the "beginning of the file" is the beginning of the external
   file, the final contents of foo.dat should be the single integer 999.
   If it refers to the beginning of the file object, *and* the beginning
   of a file in Append_File mode is considered to be the point at which
   it was opened, foo.dat should contain 4 integers: 1, 2, 3, and 999.
   (The previously written values 4, 5, and 6 are lost in either case).

   It would be easier and more intuitive, IMHO, for Reset to go to the
   beginning of the external file, but I can't infer this behavior from
   the RM.  The note in AARM95-A.10.2(4.a):

      The behavior of Reset should be similar to closing a file and
      reopening it with the given mode.

   tends to support this, but it's not binding.

   On the other hand, if Reset goes back to the beginning of the external
   file, there's no easy way to go back to the position at which it was
   opened for appending.  (This is probably no great loss.)

****************************************************************

!section A.8.2(16)
!subject Questions about Append_File mode
!reference AI95-00085
!reference RM95-A.8.2(16)
!reference RM95-A.7(2)
!reference AARM-A.10.2(4.a)
!from Tucker Taft 95-10-30
!reference 95-5373.h Tucker Taft 95-10-30>>
!discussion

I certainly believe that Reset(File, Mode(File)) is equivalent 
to simply Reset(File).  I can't imagine any other meaningful
interpretation for A.8.2(16).

As far as external vs. internal file, I believe that 
the wording in A.8.2(16) is sloppy, and whenever it 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 A.7(2)).  It makes no difference whether
the file was initially opened in append mode, or was reset to
that mode somewhere along the way.  

The annotation in A.10.2(4.a) seems to make this intent clear, 
by indicating 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.

****************************************************************

Questions? Ask the ACAA Technical Agent