CVS difference for ais/ai-00283.txt

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

--- ais/ai-00283.txt	2002/02/07 04:56:42	1.6
+++ ais/ai-00283.txt	2002/06/11 05:15:50	1.7
@@ -1,7 +1,10 @@
-!standard A.12.01    (28)                               01-12-26  AI95-00283/00
+!standard A.12.01    (28)                               02-06-10  AI95-00283/01
+!standard A.08.02    (03)
 !standard A.08.02    (10)
 !standard A.08.02    (16)
-!class amendment 01-12-27
+!standard A.08       (01)
+!class binding interpretation 02-06-10
+!status work item 02-06-10
 !status received 01-12-14
 !priority Low
 !difficulty Medium
@@ -9,18 +12,121 @@
 
 !summary
 
-(TBD.)
+Stream files are not truncated by Close or Reset.
 
-!problem
+!question
 
-!proposal
+For Stream_IO, the standard indicates that Reset truncates a file after the
+last write position and it is painful (and sometimes erroneous) to do a dummy
+Write at the end of the file before a Reset on this file from Out_File mode to
+In_File mode. There is similar behavior for Close. Is this behavior
+intended? (No.)
 
+!recommendation
+
+Stream_IO files are not sequential files, and are not truncated on Close
+and Reset as described in A.8.2(10) and A.8.2(16).
+
+!wording
+
+Italicize "stream file" in A.8(1) to signify a definition.
+
+Add "stream" to the list of kinds of input-output with Out_File as the default
+parameter in A.8.2(3).
+
+Replace A.8.2(28) by:
+
+The subprograms given in subclause A.8.2 for the control of external files
+are available for stream files. The subprogram End_of_File has the same effect
+as the corresponding subprogram given in subclause A.8.3 for sequential
+input-output.
+
 !discussion
 
-!example
+A compiler survey shows that most Ada 95 compilers truncate stream files on
+Open. This is much cheaper on Unix systems than truncating on Close as is
+described in the standard.
+
+However, truncating on Open means that all of the data in the file is discarded.
+If the application opens a stream file, positions it, writes a few items,
+positions it to the end, and closes it, all of the data not written by this
+set of operations should remain intact. Thus, the behavior of most compilers
+is incorrect.
+
+We considered requiring truncation as described in the RM. However, this
+is expensive on Unix systems (which do not have a truncate file operation),
+and no compiler currently implements it. Moreover, this is not particularly
+useful functionality. The behavior of existing compilers is easily
+accomplished by a Delete followed by Create sequence.
+
+The AARM indicates that stream files are not sequential files. This implies
+that behavior specific to sequential files (such as truncation) is not
+intended. On the other hand, if stream files are not sequential files for
+the purposes of A.8.2, what are they? The standard specifically does not
+define "stream file" as a term. And the equivalence in A.12.1(28) specifies
+"Sequential_IO", so arguably the behavior of sequential files applies.
+
+Thus we correct the oversight of defining the term "stream file", and we
+remove the reference to Sequential_IO from the specification of these
+routines. The wording used is similar to that used in the definition of
+Text_IO (A.10.2(1)). Having done so, the specific requirements in A.8.2 no
+longer apply to stream files. We also do a minor repair of the wording to
+describe the default mode for Create for stream files. Otherwise, no changes
+to A.8.2 are necessary.
+
+!corrigendum A.8(01)
+
+@drepl
+Two kinds of access to external files are defined in this subclause:
+@i<sequential access> and @i<direct access>. The corresponding file types and
+the associated operations are provided by the generic packages Sequential_IO
+and Direct_IO. A file object to be used for sequential access is called a
+@i<sequential file>, and one to be used for direct access is called a
+@i<direct file>. Access to stream files is described in A.12.1.
+@dby
+Two kinds of access to external files are defined in this subclause:
+@i<sequential access> and @i<direct access>. The corresponding file types and
+the associated operations are provided by the generic packages Sequential_IO
+and Direct_IO. A file object to be used for sequential access is called a
+@i<sequential file>, and one to be used for direct access is called a
+@i<direct file>. Access to @i<stream file>s is described in A.12.1.
+
+!corrigendum A.8.2(03)
+
+@drepl
+Establishes a new external file, with the given name and form, and associates
+this external file with the given file. The given file is left open. The
+current mode of the given file is set to the given access mode. The default
+access mode is the mode Out_File for sequential and text input-output; it is
+the mode Inout_File for direct input-output. For direct access, the size of the
+created file is implementation defined.
+@dby
+Establishes a new external file, with the given name and form, and associates
+this external file with the given file. The given file is left open. The
+current mode of the given file is set to the given access mode. The default
+access mode is the mode Out_File for sequential, stream, and text input-output;
+it is the mode Inout_File for direct input-output. For direct access, the
+size of the created file is implementation defined.
+
+
+!corrigendum A.12.1(28)
+
+@drepl
+The subprograms Create, Open, Close, Delete, Reset, Mode, Name, Form, Is_Open,
+and End_of_File have the same effect as the corresponding subprograms in
+Sequential_IO (see A.8.2).
+@dby
+The subprograms given in subclause A.8.2 for the control of external files
+(Create, Open, Close, Delete, Reset, Mode, Name, Form, and Is_Open) are
+available for stream files. The subprogram End_of_File has the same effect
+as the corresponding subprogram given in subclause A.8.3 for sequential
+input-output.
 
 !ACATS test
 
+An ACATS test needs to be created to insure that stream files are not truncated
+except on Create.
+
 !appendix
 
 !topic Inout_File mode missing for Ada.Streams.Stream_Io
@@ -337,6 +443,35 @@
 updating, for example), they're out of luck with most implementations.
 
 We'll have to discuss the best approach at the upcoming meeting.
+
+*************************************************************
+
+From Minutes of ARG meeting 15, February 2002, Cupertino CA
+
+Randy describes the problem and the result of his compiler survey (most
+compilers use the same algorithm for truncation as for Sequential_IO: truncate
+on open for Out_File).
+
+The current behavior of most compilers is a bug: it causes any data already in
+the file to be discarded, even if it is not going to be overwritten and even if
+the user has taken precautions to move the current index before closing. The
+group agrees that this is wrong.
+
+Tucker comments that if you don't truncate on open, it is expensive to truncate
+at close on Unix systems. There are probably other systems with this property.
+
+Pascal notes that if we don't truncate, we need to provide a way for the user
+to do it. Tucker notes that no existing implementation truncates on close, so
+we only need to provide what is currently available. Delete followed by Create
+would accomplish that.
+
+Therefore, the group settles on no truncation of Stream_IO files, except of
+course by Create in In_File or Out_File modes. This should be accomplished by
+fixing the equivalence so it clearly doesn't imply truncation.
+
+Approve intent of the AI: 3-0-3
+
+Randy will write the wording.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent