!standard A.8.2    (02)                               99-07-08  AI95-00056/02
!class confirmation 95-06-25
!status WG9 approved 95-06-14
!status ARG approved (subject to editorial review) 8-0-2  95-11-01
!status received 95-06-25
!subject Create(Mode => Append_File)

!summary

The Create procedures in Sequential_IO and Text_IO accept a mode;
an exception is not raised merely because the mode is Append_File
or In_File.  If the file cannot be created due to the mode,
Use_Error is raised.

!question

For Text_IO and Sequential_IO, what are the semantics of calling Create
with Mode => Append_File?  What about In_File?  Does it matter whether
or not the external file already exists?

!response

There seems to be no harm in allowing creation of files of mode
Append_File and In_File.  For Append_File mode, the semantics are
similar to Out_File.  For In_File mode, no writing is possible without a
Reset, but reading is possible, and might make sense on some operating
systems (for example, named pipes in Unix).  As stated in A.8.2(5), if
the underlying system cannot create the file with that mode, Use_Error
is raised.

!ACATS test

ACATS tests CXA8002 and CXAA001 test Append_File modes on Create.
ACATS tests CE2102D, CE2102I, CE3102E, and CE3104A test In_File modes on
Create.

!appendix

!section A.8.2(02)
!subject Create(Mode => Append_File)
!reference RM95-A.8.2(2-5)
!from Keith Thompson 95-06-91
!reference as: 95-5161.a Keith Thompson 95-6-19>>
!discussion

For Text_IO and Sequential_IO, what are the semantics of calling Create
with Mode => Append_File?  Is this exactly equivalent to Mode => Out_File
(other than the result of subsequent calls to Mode)?  Does it matter
whether or not the external file already exists?

One could argue that Append_File only makes sense if there's something
there to append to.

In both cases are:
1. It must be accepted.
2. It must be rejected (i.e., raise an exception)
3. It's implementation-defined.

Note that some of the 2.0 ACVC tests (e.g., cxa8002 and cxaa001) assume
that it must be accepted.

Note also that, if it had been intended to restrict Create to certain
modes, it would have been easy to do so by using a subtype of File_Mode.

Similarly, what about Create with Mode => In_File?  Obviously one can't
then write anything to the file, barring a call to Reset.

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

!section A.8.2(02)
!subject Create(Mode => Append_File)
!reference RM95-A.8.2(2-5)
!reference 95-5161.a Keith Thompson 95-6-19
!from Keith Thompson 95-06-91
!reference as: 95-5162.a Keith Thompson 95-6-20>>
!discussion

In my last message, I wrote:

> In both cases are:
> 1. It must be accepted.
> 2. It must be rejected (i.e., raise an exception)
> 3. It's implementation-defined.

I meant "The possible cases are: ...".

Oops.

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

!section A.8.2(02)
!subject Create(Mode => Append_File)
!reference RM95-A.8.2(2-5)
!reference 95-5161.a Keith Thompson 95-6-19
!from Robert Dewar 95-20-06 13:45 GMT
!reference as: 95-5163.a Robert Dewar 95-6-20>>
!discussion

In answering Keith's question about what modes are required for Text_IO,
be sure to look at the 1.11 ACVC tests, which in practice define what
is expected, because compilers for years have followed these tests. In
particular these tests *do* require some idiotic combinations (I know
because I had to make sure these idiotic combinations were handled by
GNAT).

On the other hand the Text_IO tests in 1.11 not only do NOT require the
kind of backscanning that one might think was necessary when reading
a string like 13#456 as an integer (the RM seems to say you should
read 13 and quit at he #), but actually *require* that you do NOT
try this kind of backscanning (i.e. in this case you must raise
data error). Of course here the ACVC interpretation is the more
sensible one, and implementors are happy to follow it. Again, GNAT
found this out by experience, I implemented all the circuitry for
the minimal syntactic scan, then found I was failing tests till I
ripped it out!

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

!section A.8.2(02)
!subject Create(Mode => Append_File)
!reference RM95-A.8.2(2-5)
!from David Emery 95-06-20
!reference as: 95-5164.a David_Emery_at_1-BCCDFA@CCGATE.HAC.COM 95-6-20>>
!discussion

The POSIX semantics of Append option for files is that all
output operations seek to the end of file before conducting
a write.

For Create on text and sequential I/O files, this is the normal,
expected behavior.  Therefore, I'd expect this to be accepted
(and to be redundant).

The POSIX semantics for Append option would generally conflict
with the behavior of a Direct I/O file.  What should happen
here?  I'd expect Use_Error.  The alternative behavior would
be to support file positioning for reads, but all writes are
appended to the end of the file.  (This is the 'normal POSIX
behavior' for files opened for input/output with append mode,
as POSIX supports file positioning/seeking on all regular files.)

There is at least one instance where Create (mode => in_file)
would make sense, and that's where the file being created
is actually a POSIX named pipe/FIFO that will also be opened for
writing by some other program/process/task/etc.  The semantics
of POSIX pipes/named FIFOs are sufficiently tricky that it may well
make sense for the reader to create the pipe, and the writer to
open the previously created pipe.

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