CVS difference for ais/ai-00085.txt

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

--- ais/ai-00085.txt	1998/09/30 22:22:11	1.2
+++ ais/ai-00085.txt	1998/10/01 03:20:24	1.3
@@ -216,3 +216,1689 @@
 properties of the external file, not of the "internal" file.
 
 ****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 8:36 AM
+Subject: 	Re: AI95-00085
+
+<<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.
+>>
+
+I find this FAR too vague. Obviously if poisitioning is not supported
+at all (a system with only tapes :-) then no argument.
+
+But how about a unix-like system in which general positioning is of
+course supported, but you *prefer* to use some specific OS facility
+to implement e.g. append mode files, which does not support the
+positioning that is needed. Are you allowed to blow away the call
+with a use_error. I think the answer should be no!
+
+There should be maximum pressure to make your IO system conform to the
+Ada model, and I dislike strong suggestions to the contrary. I think
+this paragraph should be removed from the AI. It adds nothing, except
+an unwelcome suggestion that this kind of compromise is perfectly OK.
+
+****************************************************************
+
+From: 	Pascal Leroy[SMTP:phl@Rational.Com]
+Sent: 	Thursday, April 09, 1998 10:55 AM
+Subject: 	Re: AI95-00085
+
+> But how about a unix-like system in which general positioning is of
+> course supported, but you *prefer* to use some specific OS facility
+> to implement e.g. append mode files, which does not support the
+> positioning that is needed. Are you allowed to blow away the call
+> with a use_error. I think the answer should be no!
+
+But the feeling at the last meeting was precisely that the implementation
+should be allowed to use Unix O_APPEND, and that if it does so it probably has
+to raise Use_Error on a call to Set_Index for a stream that is open in
+Append_Mode.
+
+It seems to me that requiring an implementation to support Set_Index on a
+stream in Append_Mode effectively precludes use of O_APPEND, and that's
+annoying.
+
+Pascal
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 9:10 AM
+Subject: 	Re: AI95-00085
+
+<<It seems to me that requiring an implementation to support Set_Index on a
+stream in Append_Mode effectively precludes use of O_APPEND, and that's
+annoying.
+>>
+
+Why is that annoying?
+
+
+If people want to use Unix-specific I/O, please do it directly! The whole
+idea in defining an I/O facility at the language level is for portability.
+Yes, it is frustrating when the models do not match, but that's too bad,
+since models between operating systems do not match precisely, this is
+inevitable. I think the decision to allow O_APPEND here is plain wrong.
+It is perfectly possible to implenment the Ada I/O facilities without
+allowing O_APPEND.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 9:15 AM
+Subject: 	Re: AI95-00085
+
+Incidentally, I absolutely agree that the design of the Ada with respect
+to Append was injudicious. I suspect that whoever did the design simply
+did not take the effort to look at the Unix semantics.
+
+But there are only two acceptable approaches in my mind at this stage:
+
+1. Change the language to match the Unix semantics
+
+2. Insist on the (perfectly possible to meet even on Unix) requirement
+that the implementation implement the language as chosen.
+
+The permission not to implement things in the RM is supposed to handle
+cases where it is impractical or impossible to implement things right,
+not simply cases where implementing things right is, to use Pascal's
+word, "annoying".
+
+****************************************************************
+
+From: 	Pascal Leroy[SMTP:phl@Rational.Com]
+Sent: 	Thursday, April 09, 1998 11:43 AM
+Subject: 	Re: AI95-00085
+
+> 1. Change the language to match the Unix semantics
+
+Well, if you ask me, the notion of calling Set_Index on a stream in
+Append_Mode if pretty weird, and it's not clear what the semantics of such a
+call should be.  Say that after calling Set_Index, I call Write: what happens?
+ Does it write at the end of the file?  At the current point?  Does it
+truncate the file?
+
+At the very least, these questions require clarification, and this is not
+changing the language.  I am tempted to say that Set_Index in Append_Mode is
+likely to be a programming error, and should always raise some exception (and
+I now regret that I didn't write the AI in this direction in the first place).
+
+> 2. Insist on the (perfectly possible to meet even on Unix) requirement
+> that the implementation implement the language as chosen.
+>
+> The permission not to implement things in the RM is supposed to handle
+> cases where it is impractical or impossible to implement things right,
+> not simply cases where implementing things right is, to use Pascal's
+> word, "annoying".
+
+I was not thinking in terms of implementation, but in terms of usage.  We have
+many users who want to mix Ada and C I/Os on the same file.  I would find it
+rather unpleasant if an Ada Append_Mode file was not opened with O_APPEND, or
+if passing an O_APPEND file to Ada caused it to be closed and reopened so that
+Ada can do its silly simulation.
+
+Pascal
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 9:46 AM
+Subject: 	Re: AI95-00085
+
+<<I was not thinking in terms of implementation, but in terms of usage.  We have
+many users who want to mix Ada and C I/Os on the same file.  I would find it
+rather unpleasant if an Ada Append_Mode file was not opened with O_APPEND, or
+if passing an O_APPEND file to Ada caused it to be closed and reopened so that
+Ada can do its silly simulation.
+>>
+
+Mixing Ada and C I/O may or may not succeed. It is not a requirement that
+it work smoothly, just something nice to have. You are free to implement
+a form parameter to ensure this smooth interchange. As I am sure you know
+GNAT takes a different tack, we allow a file to be opened using the stream
+identifier passed in from C, and that ensures a common view of the file.
+
+****************************************************************
+
+From: 	Robert I. Eachus[SMTP:eachus@mitre.org]
+Sent: 	Thursday, April 09, 1998 10:10 AM
+Subject: 	Re: AI95-00085
+
+At 10:15 AM 4/9/98 EDT, Robert Dewar wrote:
+>The permission not to implement things in the RM is supposed to handle
+>cases where it is impractical or impossible to implement things right,
+>not simply cases where implementing things right is, to use Pascal's
+>word, "annoying".
+
+   Is an implementation allowed to silently close and reopen an (external)
+file in response to a Set_Position, if it was originally opened in Append
+mode?  I assume so, and that this would be the preferable option for Unix.
+(I'm not sure what the right thing to do is if an unnamed file/pipe was
+opened in append mode though.  Probably, that is a case for Use_Error.)  
+
+                                        Robert I. Eachus
+
+with Standard_Disclaimer;
+use  Standard_Disclaimer;
+function Message (Text: in Clever_Ideas) return Better_Ideas is...
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Thursday, April 09, 1998 10:42 AM
+Subject: 	Re: AI95-00085
+
+Another possibility would be to use O_APPEND mode until a
+Set_Index is called, and only then go through the trouble of
+re-opening in non-append mode rather than raising Use_Error,
+with the presumption that Set_Index will be used rarely for
+files opened in append mode.
+Effectively Set_Index would be almost like a Reset(F, Mode => Out_File)
+(though of course Mode(F) would still return Append_File).
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 11:50 AM
+Subject: 	Re: AI95-00085
+
+<<Another possibility would be to use O_APPEND mode until a
+Set_Index is called, and only then go through the trouble of
+re-opening in non-append mode rather than raising Use_Error,
+with the presumption that Set_Index will be used rarely for
+files opened in append mode.
+Effectively Set_Index would be almost like a Reset(F, Mode => Out_File)
+(though of course Mode(F) would still return Append_File).
+>>
+
+That's perfectly reasonable. We do something like this in GNAT when you
+switch from read to write mode for stream_io, we first open in read only
+mode, then reopen in update mode when you switch.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 11:47 AM
+Subject: 	Re: AI95-00085
+
+<<   Is an implementation allowed to silently close and reopen an (external)
+file in response to a Set_Position, if it was originally opened in Append
+mode?  I assume so, and that this would be the preferable option for Unix.
+(I'm not sure what the right thing to do is if an unnamed file/pipe was
+opened in append mode though.  Probably, that is a case for Use_Error.)
+>>
+
+Of course you are allowed to silently close and reopen in response to 
+Set_Position (you can do it on every read if you like :-)
+
+****************************************************************
+
+From: 	Randy Brukardt[SMTP:Randy@rrsoftware.com]
+Sent: 	Thursday, April 09, 1998 12:29 PM
+Subject: 	RE: AI95-00085
+
+I've been following this discussion, and I just don't get it.  Probably the 
+problem is my lack of experience with the common usages of Unix.
+
+I just don't understand why anyone would want to use O_APPEND on a 
+positionable device.  When I studied the Unix documents, I just viewed 
+O_APPEND as (to borrow Robert's term) a
+junk mode.  Why would anyone WANT to disallow positioning on their file?  I 
+can see that it may not matter in some cases, but I can't see any reason 
+that anyone would want the defined behavior of O_APPEND.  I would expect 
+that most users just want to start writing at the end of the file, and 
+don't care about positioning.
+
+I would expect that non-positionable devices would essentially be in append 
+mode at all times, so there is no need for some junk mode in that case, 
+either.
+
+The Ada Append_Mode matches the behavior I would expect exactly: starting 
+writing at the end of the file, but has no other semantic effects.  If this 
+means not using a junk mode, so be it.
+
+It was always my view that Append is a feature of Open/Create, not a mode. 
+ It should have been implemented as an optional parameter to Open/Create.
+
+As far as mixing Ada and C I/O, I don't see a problem.  If the file is 
+opened in C, and imported into Ada somehow, there cannot be a problem. 
+ That is outside of anything in the Ada standard, so do whatever you want - 
+raise Use_Error anywhere you have to.  If the file is opened in Ada and 
+passed to C, there shouldn't a be a problem.  Since O_APPEND disallows 
+various operations, I don't see how not using it on a file could break any 
+existing C code (unless that C code was completely broken in the first 
+place).  In any, I would expect most code that takes files to work 
+irregardless of the file mode.
+
+If you absolutely have to have O_APPEND opens, add a form parameter 
+"Open_with_junk_O_Append" and open it that way.  Then you can raise 
+Use_Error anywhere you like.
+
+I agree with Robert that there is no good reason to break portability of 
+software by allowing compilers to raise Use_Error when it is easy to avoid 
+it.  This is especially so in order to support junk file options of a 
+particular (admittedly popular) operating system.
+
+
+						Randy.
+
+****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Thursday, April 09, 1998 2:14 PM
+Subject: 	RE: AI95-00085
+
+> I've been following this discussion, and I just don't get it.  Probably the 
+> problem is my lack of experience with the common usages of Unix.
+> 
+> I just don't understand why anyone would want to use O_APPEND on a 
+> positionable device.  When I studied the Unix documents, I just viewed 
+> O_APPEND as (to borrow Robert's term) a
+> junk mode.  Why would anyone WANT to disallow positioning on their file?  I 
+> can see that it may not matter in some cases, but I can't see any reason 
+> that anyone would want the defined behavior of O_APPEND.  I would expect 
+> that most users just want to start writing at the end of the file, and 
+> don't care about positioning.
+
+O_APPEND is a relatively new mode for Unix (speaking geologically here).
+It was invented to solve the problem of having multiple processes
+all writing to the same log file at the same time, wanting all messages
+to end up at the end, no matter which process wrote them.
+
+Without O_APPEND, each process maintains its own internal idea of what
+is its position in the file, and even though it may position to the
+end when it first opens the file, because other processes are writing
+to the same file simultaneously, its position may no longer correspond
+to the end when it gets around to writing.
+
+In my view, the "Append_File" mode in Ada is intended to allow the use
+of O_APPEND, but not require it, at least for Sequential_IO.  
+However, A.14 makes it clear that each stream file object has its
+own current_index, presuming the file supports positioning.  
+This would seem to preclude the use of O_APPEND, with its automatic 
+position-to-the-end semantics, unless positioning is disallowed
+for the file.   Hence it seems necessary to either raise Use_Error
+on Set_Index, or not use O_APPEND mode for stream files.
+Presumably a Form parameter could be used to control which
+semantics are preferred.
+
+> I would expect that non-positionable devices would essentially be in append 
+> mode at all times, so there is no need for some junk mode in that case, 
+> either.
+> 
+> The Ada Append_Mode matches the behavior I would expect exactly: starting 
+> writing at the end of the file, but has no other semantic effects.  If this 
+> means not using a junk mode, so be it.
+> 
+> It was always my view that Append is a feature of Open/Create, not a mode. 
+>  It should have been implemented as an optional parameter to Open/Create.
+
+The issue is what happens in the presence of multiple processes all
+appending to the same file.
+
+> I agree with Robert that there is no good reason to break portability of 
+> software by allowing compilers to raise Use_Error when it is easy to avoid 
+> it.  This is especially so in order to support junk file options of a 
+> particular (admittedly popular) operating system.
+
+It seems better to support either approach by use of a Form parameter.
+It is not clear to me which should be the default for Append_File
+in the absence of a Form parameter, but it now seems clear to me
+that O_APPEND mode is inconsistent with the A.14(4) requirement 
+that each stream file maintains its own current index, unless 
+positioning is not allowed for the file (i.e. Set_Index raises Use_Error).
+
+> 						Randy.
+
+-Tuck
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Thursday, April 09, 1998 2:41 PM
+Subject: 	Re: AI95-00085
+
+This kind of Ada-centric view (of append-only file access modes)
+is typical of the kind of attitude that has held Ada back.
+
+The Ada'95 append mode was intended to allow access to OS-provided
+append modes.  If we now prevent it from mapping in a sensible
+way, we just make Ada look absurd.  
+
+--Ted
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 2:40 PM
+Subject: 	Re: AI95-00085
+
+<<This kind of Ada-centric view (of append-only file access modes)
+is typical of the kind of attitude that has held Ada back.
+
+The Ada'95 append mode was intended to allow access to OS-provided
+append modes.  If we now prevent it from mapping in a sensible
+way, we just make Ada look absurd.
+>>
+
+Are you specifically talking about O_APPEND here?
+
+We may say that the Ada 95 append mode was intended to allow access to
+OS-provided append modes, but all OS's do not provide the same stuff, are
+you saying that you think append mode should be entirely implementation
+dependent?
+
+****************************************************************
+
+From: 	Randy Brukardt[SMTP:Randy@rrsoftware.com]
+Sent: 	Thursday, April 09, 1998 3:16 PM
+Subject: 	RE: AI95-00085
+
+>O_APPEND is a relatively new mode for Unix (speaking geologically here).
+>It was invented to solve the problem of having multiple processes
+>all writing to the same log file at the same time, wanting all messages
+>to end up at the end, no matter which process wrote them.
+
+OK.  Sounds like my impression is correct: it is a junk mode created to 
+patch around the lack of kernel-level sharing, good synchronization 
+methods, and shared address space threads in [basic] Unix, and a lack of 
+awareness of tasking issues in C.  Such stuff is totally unnecessary from 
+an Ada perspective, which has good synchronization methods and tasking.
+
+This just makes it a C-to-Ada interface issue, and such issues are best 
+handled with forms and pragmas, not by messing with the basic Ada 
+semantics.
+
+					Randy.
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Thursday, April 09, 1998 4:10 PM
+Subject: 	Re: AI95-00085
+
+| Of course you are allowed to silently close and reopen in response to 
+| Set_Position (you can do it on every read if you like :-)
+
+The above would be very unwise in a UNIX system, since the semantics
+would be much different than if the file were to stay open.  In particular,
+a file that is open cannot go away, even if it is (concurrently) unlinked,
+whereas once an unlinked file is closed it goes away.
+
+I suppose this is another respect in which the ARM semantics don't match
+UNIX semantics.  The ARM says that when you Delete a file it ceases to exist.
+In UNIX, a file does not cease to exist until the last close.
+
+I can't imagine that existing Ada implementations on UNIX systems are
+required to somehow defeat the UNIX last-close semantics, so I guess the
+requirement about files ceasing to exist immediately after Delete is
+not being enforced.
+
+Given this, why not leave the Append semantics open enough that a direct
+mapping to O_APPEND mode is OK?
+
+--Ted
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Thursday, April 09, 1998 4:24 PM
+Subject: 	RE: AI95-00085
+
+| I just don't understand why anyone would want to use O_APPEND ...
+| ... junk mode.  ... I can't see any reason 
+| that anyone would want the defined behavior of O_APPEND. ...
+
+O_APPEND serves a critical purpose, i.e., a safe way to write to
+log-files by multiple processes.  When you use it, you DON'T want
+to allow positioning the file, and the mode prevents you from
+doing so; however, the file normally is disk file and so
+positionable if opened in other modes.
+
+[In case it is not sufficiently obvious, O_APPEND does something
+you *cannot* do with lseek() to the end of the file, because the
+lseek() and the following write operation are not atomic, and so
+one process could end up writing on top of something just
+previously logged by another.]
+
+| It was always my view that Append is a feature of Open/Create, not a mode. 
+| It should have been implemented as an optional parameter to Open/Create.
+
+??????????  Append *is* something you specify in Open/Create.
+
+--Ted
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Thursday, April 09, 1998 4:31 PM
+Subject: 	Re: AI95-00085
+
+| Are you specifically talking about O_APPEND here?
+
+Certainly it should include O_APPEND, or more specifically the
+append-only (nonrepositionable, always-write-at the end) semantics.
+Otherwise, if the semantics could be emulated using other existing
+Ada operations, there would be no reason to add an append mode
+to the language.
+
+| We may say that the Ada 95 append mode was intended to allow access to
+| OS-provided append modes, but all OS's do not provide the same stuff, are
+| you saying that you think append mode should be entirely implementation
+| dependent?
+
+Not "entirely", but certainly loose enough to allow mapping to O_Append.
+
+--Ted
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Thursday, April 09, 1998 4:27 PM
+Subject: 	RE: AI95-00085
+
+| However, A.14 makes it clear that each stream file object has its
+| own current_index, presuming the file supports positioning.  
+| This would seem to preclude the use of O_APPEND, with its automatic 
+| position-to-the-end semantics, unless positioning is disallowed
+| for the file.   Hence it seems necessary to either raise Use_Error
+| on Set_Index, or not use O_APPEND mode for stream files.
+
+Presumably the only issue here is whether we want people to be able
+to use stream I/O to write log files from Ada programs in a concurrent
+environment.  I've been presuming everyone would agree that the answer
+is "yes".
+
+--Ted
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 4:45 PM
+Subject: 	RE: AI95-00085
+
+<<O_APPEND serves a critical purpose, i.e., a safe way to write to
+log-files by multiple processes.  When you use it, you DON'T want
+to allow positioning the file, and the mode prevents you from
+doing so; however, the file normally is disk file and so
+positionable if opened in other modes.
+>>
+
+It is inappropriate to expect the Ada feature to provide this functionality.
+It is not documented to do so, and relying on it to do so, because you know
+your implementation happens to work this way is a style of non-portable
+programming that is not to be encouraged. If you want to rely on a Unix
+specific feature, use the Unix specific feature directly!
+
+<<??????????  Append *is* something you specify in Open/Create.
+>>
+
+No, it is a mode, and can be reset -- I very much agree that it should have
+been an optional parameter of Open/Create, but it is not!
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 4:42 PM
+Subject: 	Re: AI95-00085
+
+<<I can't imagine that existing Ada implementations on UNIX systems are
+required to somehow defeat the UNIX last-close semantics, so I guess the
+requirement about files ceasing to exist immediately after Delete is
+not being enforced.
+>>
+
+Certainly GNAT does reopens in some cases, precisely to get a BETTER
+match to Unix semantics (i.e. do not open in update mode until you know
+you are going to be writing).
+
+<<Given this, why not leave the Append semantics open enough that a direct
+mapping to O_APPEND mode is OK?
+>>
+
+Because it introduces unnecessary non-portability.
+
+If you think that it is fine not to be able to position, then your 
+implementation can use O_APPEND *until* you reposition.
+
+If you want to use O_APPEND and reposition you are out of luck anyway!
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 4:46 PM
+Subject: 	RE: AI95-00085
+
+<<Presumably the only issue here is whether we want people to be able
+to use stream I/O to write log files from Ada programs in a concurrent
+environment.  I've been presuming everyone would agree that the answer
+is "yes".
+>>
+
+Absolutely NOT!
+
+If you want to rely on Unix specific features for writing log files in
+a concurrent safe manner, then you should use the C streams and specific
+C/Unix features to do this. You can still use stream attributes in Ada
+to write and read the data. I see no particular merit in twisting Stream_IO
+into service for this purpose, since the resulting code would be annoyingly
+and obscurely implementation dependent.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 4:52 PM
+Subject: 	RE: AI95-00085
+
+<<Pardon me, but please refrain from calling "jun"k that which you
+simply may not understand.  It is precisely "kernel-level sharing"
+and "good synchronization" that is provided by O_APPEND. The
+kernel insures that all writes to the file are at the end, thereby
+enforcing data integrity, in a way that otherwise is impossible.
+>>
+
+What he means by junk (and I concur with his choice of the term) is some
+operating specific special feature meant to solve some problem in a peculiar
+operating system idiosyncratic feature. This feature may be interesting for
+Unix users, but it has nothing to do with Ada, and *allowing* (rather than
+insisting, which is impractical) implementations to map a specific restricted
+style of Ada stream_io (without a form parameter) to this strange Unix feature
+is not only not helpful it is actively harmful.
+
+If an implentor wants to provide this feature, the proper way to do it is
+with a form parameter, that specifies O_APPEND mode is to be used, and then
+of course you are free to enforce any restrictions you like.
+
+This is a perfectly valid approach, it makes the implementation dependence
+apparent, which is a GOOD THING, while preserving the capability you think
+is important in this specific environment.
+
+****************************************************************
+
+From: 	Norman H Cohen[SMTP:ncohen@us.ibm.com]
+Sent: 	Thursday, April 09, 1998 4:52 PM
+Subject: 	Re: AI95-00085
+
+It seems quite reasonable to assert that repositioning a file opened in append
+mode raises Use_Error, and to state that this happens portably and predictably
+for all implementations (Write Once, Blow Up Anywhere).  This would allow Ada
+append mode to be directly mapped to Unix O_APPEND.  More importantly,
+appending and repositioning are a logically inconsistent combination.
+
+-- Norman
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Thursday, April 09, 1998 4:58 PM
+Subject: 	Re: AI95-00085
+
+<<It seems quite reasonable to assert that repositioning a file opened in append
+mode raises Use_Error, and to state that this happens portably and predictably
+for all implementations (Write Once, Blow Up Anywhere).  This would allow Ada
+append mode to be directly mapped to Unix O_APPEND.  More importantly,
+appending and repositioning are a logically inconsistent combination.
+>>
+
+It may be reasonable.
+
+It is a definite language change.
+
+It is perfectly reasonable to append, write stuff, go back and patch something
+you already wrote, position to the end, write some more, etc. so I disagree
+with the last statement.
+
+****************************************************************
+
+From: 	Jean-Pierre Rosen[SMTP:rosen.adalog@wanadoo.fr]
+Sent: 	Friday, April 10, 1998 2:19 AM
+Subject: 	Re: AI95-00085
+
+After reading the flood on this subject, I strongly concur with Robert's position, that I would rephrase this way:
+
+Those who want the semantics of a particular OS use the binding to this OS (and we do have a good binding to POSIX).
+Those who want portability across various OSes use Ada predefined services.
+
+Ted, are you discovering that portability sometimes requires the least common demoninator of various OSes ?
+----------------------------------------------------------------------------
+                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
+      Visit Adalog's web site at http://perso.wanadoo.fr/adalog
+
+****************************************************************
+
+From: 	Pascal Leroy[SMTP:phl@Rational.Com]
+Sent: 	Friday, April 10, 1998 5:46 AM
+Subject: 	Re: AI95-00085
+
+Wow!  30+ messages in my mailbox this morning on this wretched AI!  We have
+not had such a lively discussion on the ARG list for a long time.
+
+For the record, I agree with essentially everything that Ted said.
+
+> <<It seems quite reasonable to assert that repositioning a file opened in
+> append
+> mode raises Use_Error, and to state that this happens portably and
+> predictably
+> for all implementations (Write Once, Blow Up Anywhere).  This would allow
+Ada
+> append mode to be directly mapped to Unix O_APPEND.  More importantly,
+> appending and repositioning are a logically inconsistent combination.
+> >>
+>
+> It may be reasonable.
+
+I agree with Norm that appending and repositioning are probably inconsistent,
+and at the very least don't have a "natural" semantics.  So if nothing else,
+this AI _must_ define what repositioning might mean for an append stream.
+
+> It is a definite language change.
+
+Definitely not.  It is very much unclear what is the semantics of
+repositioning on an append file in the first place, and the RM doesn't give
+any clue as to what it should mean in Ada.  (In fact, it's hard to find a
+section of the RM which is less precise than A.12.1.)
+
+So whatever we decide is not a language change, only a clarification.
+
+> It is perfectly reasonable to append, write stuff, go back and patch
+> something
+> you already wrote, position to the end, write some more, etc. so I disagree
+> with the last statement.
+
+That's one possible interpretation.  Here is another one:
+
+On a stream opened in Append_Mode, Set_Index truncates the file at the
+specified position, and the next write will take place at the (new) end of the
+file.  Surely this preserve two invariants: (1) Set_Index effectively moves to
+the specified position and (2) in Append_Mode, you only write to the end of
+the file.
+
+These two interpretations are (1) legitimate (2) not substantiated by the RM
+and (3) not contradicted by the RM.
+
+Pascal
+
+_____________________________________________________________________
+Pascal Leroy                                    +33.1.30.12.09.68
+pleroy@rational.com                             +33.1.30.12.09.66 FAX
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 6:03 AM
+Subject: 	Re: AI95-00085
+
+Pascal says
+
+  Definitely not.  It is very much unclear what is the semantics of
+  repositioning on an append file in the first place, and the RM doesn't give
+  any clue as to what it should mean in Ada.  (In fact, it's hard to find a
+  section of the RM which is less precise than A.12.1.)
+
+  So whatever we decide is not a language change, only a clarification. >>
+
+Robert replies:
+
+  Well it is clear that positioning *is* allowed, so an AI that says it is
+  not allowed is clearly a language change.
+
+Pascal suggests a possible interpretation of positioning:
+
+  On a stream opened in Append_Mode, Set_Index truncates the file at the
+  specified position, and the next write will take place at the (new) end of the
+  file.  Surely this preserve two invariants: (1) Set_Index effectively moves to
+  the specified position and (2) in Append_Mode, you only write to the end of
+  the file.
+
+  These two interpretations are (1) legitimate (2) not substantiated by the RM
+  and (3) not contradicted by the RM.
+
+Robert replies
+
+  I disagree that the RM is unclear, and I do not think that Pascal's
+  interpretation here is supportable. The RM simply says about Append_File
+  that it causes the first transfer to be at the end of the file.
+
+  I think what is going on here is that people read about append, and
+  assume that for stream files it has something to do with O_APPEND in
+  Unix, and then they start importing irrelevant semantics from Unix.
+
+  When I looked at the RM, it was immediately clear to me that of course
+  you can't use Unix append mode for stream_IO Append_File, since it has
+  inconsistent semantics.
+
+  We implemented a long time ago what seemed like the obviously required
+  semantics, no one has ever complained, and no ACVC tests has contradicted
+  this. I would be *very* reluctant to swich to an interpretation like the
+  one above, which has no justification whatsoever in the RM, and might
+  well cause silent malfunction of existing programs.
+
+  Since Stream_IO is part of the core, there are 70 or so compilers that
+  are implementing some interpretation or other of how this works. Can
+  we please do a reasonably comprehensive survey of what implementors
+  are in fact doing now, to at least make sure that whatever the ARG
+  does in this non-critical area is not unnecesarily disruptive. I say
+  non-critical here, because I have not seen users get worried about
+  this issue!
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Friday, April 10, 1998 8:28 AM
+To: 	arg95@sw-eng.falls-church.va.us
+Subject: 	copy of Baker/Dewar exchange
+
+
+Robert Dewar has requested that I forward the following e-mail exchange
+between him and myself, which I intended as a private exchange, but
+Robert apparently intended for the whole ARG.
+My apologies for the length.  --Ted
+
+---------------------------------------------
+
+From baker Thu Apr  9 18:59:59 1998
+To: dewar@gnat.com
+Subject: RE: AI95-00085
+Content-Length: 556
+
+It is unfair to cite me as a satisfied user of that GNAT idiosyncracy.
+My "use" of GNAT is primarily for implementing the POSIX.5 interfaces,
+and implementing the GNAT runtime.  This feature does not come up there.
+That does not mean it is not an important functionality to real users.
+
+What really galls me about this discussion is that the reason for Append
+being added to Ada'9X was input from the POSIX Ada bindings group, and it
+specifically was intended to map O_APPEND --- despite whatever revisionist
+rhetoric you and Randy want to put out.
+
+--Ted
+
+From dewar@gnat.com Thu Apr  9 23:01 EST 1998
+Return-Path: <dewar@gnat.com>
+Received: from cs.fsu.edu by dad.cs.fsu.edu with SMTP (SMI-8.6/SMI-SVR4)
+	id XAA20500; Thu, 9 Apr 1998 23:01:25 GMT
+Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by cs.fsu.edu (8.8.8/8.7.3) with ESMTP id TAA22871 for <baker@cs.fsu.edu>; Thu, 9 Apr 1998 19:01:27 -0400 (EDT)
+Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.8.8/)
+	id WAA11205; Thu, 9 Apr 1998 22:57:37 GMT
+Received: by nile.gnat.com (5.0/1.20)
+	id AA28031; Thu, 9 Apr 98 18:59:04 EDT
+Date: Thu, 9 Apr 98 18:59:04 EDT
+From: dewar@gnat.com (Robert Dewar)
+Message-Id: <9804092259.AA28031@nile.gnat.com>
+To: Arg95@sw-eng.falls-church.va.us, baker@dad.cs.fsu.edu, dewar@gnat.com,
+        ncohen@us.ibm.com
+Subject: Re: AI95-00085
+Content-Type: text
+Content-Length: 393
+Status: RO
+
+<<If that is what you want to do, you don't need an append mode.
+You just open the file in write mode, and position to the end when you want
+to write at the end.  There is no justification for having an append mode
+if the semantics do not provide any additional capability.
+>>
+
+That's odd, the whole discussion is about *taking away* functionality from
+the current append semantics in the RM!
+
+From baker Thu Apr  9 19:15:45 1998
+To: dewar@gnat.com
+Subject: Re: AI95-00085
+Content-Length: 592
+
+| That's odd, the whole discussion is about *taking away* functionality from
+| the current append semantics in the RM!
+
+The capability that is lost from UNIX is (atomic) writes to the end
+of a file by multiple processes.  Providing that requires mapping
+directly to the OS O_APPEND mode, if there is one.  If we require the
+Ada implementation to provide some other functionality (that can be
+simulated via other existing operations, and so is not a real gain)
+that required simulation of normal append mode writes via some non-atomic
+combination of system calls, then there is a loss.
+
+--Ted
+
+From dewar@gnat.com Thu Apr  9 23:05 EST 1998
+Return-Path: <dewar@gnat.com>
+Received: from nile.gnat.com by dad.cs.fsu.edu with SMTP (SMI-8.6/SMI-SVR4)
+	id XAA20521; Thu, 9 Apr 1998 23:05:13 GMT
+Received: by nile.gnat.com (5.0/1.20)
+	id AA02217; Thu, 9 Apr 98 19:03:03 EDT
+Date: Thu, 9 Apr 98 19:03:03 EDT
+From: dewar@gnat.com (Robert Dewar)
+Message-Id: <9804092303.AA02217@nile.gnat.com>
+To: baker@dad.cs.fsu.edu, dewar@gnat.com
+Subject: RE: AI95-00085
+Content-Type: text
+Content-Length: 795
+Status: R
+
+<<What really galls me about this discussion is that the reason for Append
+being added to Ada'9X was input from the POSIX Ada bindings group, and it
+specifically was intended to map O_APPEND --- despite whatever revisionist
+rhetoric you and Randy want to put out.
+><>
+
+This is not historically accurate, there were a number of revision requests
+for append mode, and they did not mention O_APPEND (I am not even sure it
+existed then!)
+
+What puzzles me Ted, is you had years to see a plain definition that was
+obviously inconcistent with O_APPEND semantics, and so did everyone else
+have this chance. The inconsistency was mentioned several times during
+the revision process. No one seemed concerned. No one raised the issue.
+It is a bit late to be suggesting significant changes to the language!
+
+From baker Thu Apr  9 19:19:28 1998
+To: dewar@gnat.com
+Subject: RE: AI95-00085
+Content-Length: 1006
+
+| This is not historically accurate, there were a number of revision requests
+| for append mode, and they did not mention O_APPEND (I am not even sure it
+| existed then!)
+
+It certainly has existed, for many years, and has been in the
+POSIX spec. from the very beginning.  The requests where I knew
+the people who put them in (like Dave Emery) were motivated by
+experience with UNIX/POSIX applications where the functionality
+was needed.  Those requests may not have mentioned POSIX
+explicitly, so you may not have seen the connection.
+
+| What puzzles me Ted, is you had years to see a plain definition that was
+| obviously inconcistent with O_APPEND semantics, and so did everyone else
+| have this chance. The inconsistency was mentioned several times during
+| the revision process. No one seemed concerned. No one raised the issue.
+| It is a bit late to be suggesting significant changes to the language!
+
+Like several other things outside the tasking/AnnexD/AnnexC domain,
+I managed to miss this.
+
+--Ted
+
+From dewar@gnat.com Thu Apr  9 23:22 EST 1998
+Return-Path: <dewar@gnat.com>
+Received: from nile.gnat.com by dad.cs.fsu.edu with SMTP (SMI-8.6/SMI-SVR4)
+	id XAA20558; Thu, 9 Apr 1998 23:22:20 GMT
+Received: by nile.gnat.com (5.0/1.20)
+	id AA21075; Thu, 9 Apr 98 19:20:09 EDT
+Date: Thu, 9 Apr 98 19:20:09 EDT
+From: dewar@gnat.com (Robert Dewar)
+Message-Id: <9804092320.AA21075@nile.gnat.com>
+To: baker@dad.cs.fsu.edu, dewar@gnat.com
+Subject: Re: AI95-00085
+Content-Type: text
+Content-Length: 1558
+Status: RO
+
+<<The capability that is lost from UNIX is (atomic) writes to the end
+of a file by multiple processes.  Providing that requires mapping
+directly to the OS O_APPEND mode, if there is one.  If we require the
+Ada implementation to provide some other functionality (that can be
+simulated via other existing operations, and so is not a real gain)
+that required simulation of normal append mode writes via some non-atomic
+combination of system calls, then there is a loss.
+>>
+
+Wait a minute, where is the loss here? There is nothing in the RM that
+talks about atomic writes by multiple processes. Such multiple writes
+to a file are clearly undefined in the Ada semantics.
+
+I really don't understand Ted's position at all. It seems to be something 
+like:
+
+  a) weaken the Ada semantics so that Ada compilers can use O_APPEND by
+	default.
+
+  b) do not require this weakening
+
+  c) do not require the use of O_APPEND
+
+  d) if you are lucky enough to have a compiler that takes advantage of
+     this new functionality, then feel free to use it to write 
+     non-portable code.
+
+Seems quite strange to me. Ted, why do you object to a Form parameter
+something like Atomic_Append, which we all agree MUST have the semantics
+you want if it is implemented, and is rejected otherwise.
+
+Incidentally, I think Ted's history is totally wrong here.
+
+Append is seriously useful functionality for Sequential and Text_IO. Its
+provision in Stream_IO seems to have been mostly a matter of (possibly
+misguided) orthogonality.
+
+At least that is the way that Dewar remembers history!
+
+From baker Fri Apr 10 08:02:15 1998
+To: dewar@gnat.com
+Subject: Re: AI95-00085
+Content-Length: 2276
+
+Sorry to spend so much talk on such a minor matter, but not
+allowing a mapping to O_APPEND still seems fundamentally
+wrong-headed to me, your repeated assertions notwithstanding.
+I guess we are not going to agree on this one.
+
+| Wait a minute, where is the loss here?
+
+Loss of permission to access to underlying OS functionality.
+
+|   a) weaken the Ada semantics so that Ada compilers can use O_APPEND by
+| 	default.
+
+Weaken here means giving up a functionality (repositioning an
+append-only stream) that seems to have no practical use.
+
+|   b) do not require this weakening
+
+Seems to mean the same thing as below.
+
+|   c) do not require the use of O_APPEND
+
+In case the OS does not support O_APPEND.
+
+|   d) if you are lucky enough to have a compiler that takes advantage of
+|      this new functionality, then feel free to use it to write 
+|      non-portable code.
+
+I'd like to see this be the required semantics, for UNIX systems,
+e.g. by the POSIX Ada bindings.
+
+| Seems quite strange to me. Ted, why do you object to a Form parameter
+| something like Atomic_Append, which we all agree MUST have the semantics
+| you want if it is implemented, and is rejected otherwise.
+
+Does GNAT support such a form parameter?
+POSIX.5 defined an interface for this, before Ada'9X, but I have not
+seen the POSIX.5 form parameters supported.
+Moreover, last time we revised POSIX.5, people argued that we did not
+need this (complicated and unwieldy) form parameter business any more,
+given Ada'95 support for Append mode.
+
+In contrast to the form parameter, O_APPEND is very simple to
+implement (simpler than the form parameter, and simpler than
+trying to allow repositioning), and could easily become the
+defacto standard for systems that support it, if it were
+permitted.
+
+| Incidentally, I think Ted's history is totally wrong here.
+| Append is seriously useful functionality for Sequential and Text_IO. Its
+| provision in Stream_IO seems to have been mostly a matter of (possibly
+| misguided) orthogonality.
+| At least that is the way that Dewar remembers history!
+
+Yes, the addition to Stream_IO was clearly last-minute, and for
+orthogonality.
+The inclusion for Sequential and Text_IO is what I was taking about,
+where providing a mapping for O_APPEND is the historical basis.
+
+--Ted
+
+From dewar@gnat.com Fri Apr 10 12:20 EST 1998
+Return-Path: <dewar@gnat.com>
+Received: from nile.gnat.com by dad.cs.fsu.edu with SMTP (SMI-8.6/SMI-SVR4)
+	id MAA20861; Fri, 10 Apr 1998 12:20:07 GMT
+Received: by nile.gnat.com (5.0/1.20)
+	id AA22760; Fri, 10 Apr 98 08:17:54 EDT
+Date: Fri, 10 Apr 98 08:17:54 EDT
+From: dewar@gnat.com (Robert Dewar)
+Message-Id: <9804101217.AA22760@nile.gnat.com>
+To: baker@dad.cs.fsu.edu, dewar@gnat.com
+Subject: Re: AI95-00085
+Content-Type: text
+Content-Length: 5379
+Status: R
+
+<<I'd like to see this be the required semantics, for UNIX systems,
+e.g. by the POSIX Ada bindings.
+>>
+
+Ah! But that is a TOTALLY different matter. Nothing we are talking about
+here requires any compiler to actually *support* what you want.
+
+If you want to go far beyond the AI, appropriate in the context of the POSIX
+Ada bindings, but clearly not in the context of the AI, and make such a
+requirement, then that's fine, but a Form parameter is a perfectly good
+(actually preferable) path to implementing this requirement.
+
+<<Moreover, last time we revised POSIX.5, people argued that we did not
+need this (complicated and unwieldy) form parameter business any more,
+given Ada'95 support for Append mode.
+>>
+
+Too bad that people did not know what they were talking about! Clealry
+the Ada semantics as defined at the time did not support this argument.
+This is not an unknown issue, as my comments quoted from the GNAT sources
+show, I was aware of this issue years ago when I first implemented append
+mode. Indeed it seemed quite obvious to me that the RM was inconsitent
+with the use of the Unix append mode. I found it annoying, but there are
+many things an implementor finds annoying with the language! Actually I
+found it much more annoying that you don't know whether to open a file
+in read or update mode when you first open it.
+
+<<Does GNAT support such a form parameter?
+>>
+
+Certainly not! As I mentioned to you earlier, no customer of ours has ever
+indicated that this was of interest.
+
+<<The inclusion for Sequential and Text_IO is what I was taking about,
+where providing a mapping for O_APPEND is the historical basis.
+>>
+
+No, that's wrong. The desire for append here has nothing necessarily to do
+with synchronization with multiple processes. It is a much simpler
+requirement, namely to be able to write starting at the end of the file.
+Recall that neither Sequential_IO nor Text_IO allow the possibility of
+positioning, so this fundamental capability, needed on all operating
+systems, and available on all operating systems, was missing from Ada 83.
+The revision requests in this area mentioned nothing about O_APPEND or the
+need for providing this unix/posix special synchronization mechanism.
+
+Indeed, NONE of the Ada 95 discussions raised the issue of this syncrhonization
+question. Perhaps it was always in the minds of the Posix folks who were
+involved in the discussion, and perhaps they always *knew* that this was
+the crucial issue, but if so, it is too bad that they (a) did not speak up
+and (b) let the language be designed in a manner inconsistent with the
+use of Unix append without comment.
+
+I have been involved in all the Ada 95 discussions, but not the Posix
+discussions. However, I would comment that I always thought that the
+basic motivation for the Posix append was the more general requirement.
+After all, the main use of the append mode in Unix is for the simple
+general requirement of doing appends. Even in Unix, the synchronization
+lockout use is somewhat specialized (at least that is my experience in
+seeing the mode used in real programs).
+
+By the way, what does the ANSI C standard have to say about appending
+exactly, can someone provide the quote. I think compatibility with C,
+as opposed to compatibility with Unix, always provides a stronger
+form of the compatibility argument.
+
+I certainly have no objection to the Ada/Posix interface requiring support
+of the Posix/Unix type append. However
+
+*even if* the AI is written to allow the default behavior to mirror
+the Posix way of doing append, I would be *really annoyed* if the Posix
+binding required you to change your compiler to implement things this
+way.
+
+Ted says
+
+<<In contrast to the form parameter, O_APPEND is very simple to
+implement (simpler than the form parameter, and simpler than
+trying to allow repositioning), and could easily become the
+defacto standard for systems that support it, if it were
+permitted.
+>>
+
+That is completely incorrect. Implementing append by changing the current
+semantics, which our customers have been using for four years is not at
+all trivial. We will have to do a survey to see who would be affected,
+and most probably implement some complex mechanism to provide back
+compatibility to those who are affected.
+
+Implementing a form parameter is a simple job which should take only a day
+or two, and be completely upwards compatible.
+
+When the ARG changes the language in a manner that requires existing
+compilers to change their implementation, and existing users to modify
+their code, they are behaving in the most aggressive manner possible.
+This level of aggression is only approrpriate for absolutely major
+issues (we did even dare to do this for the 256 character case -- have
+indeed we EVER done this).
+
+I do not begin to believe that this issue is of sufficient importance
+to warrant a requirement that existing implementations change, and I
+strongly recommend that the POSIX group meet their (very reasonable)
+requirement by other means than requiring language and implementation
+chanes.
+
+Yes, we might have done things differently 5 years ago if the issue had
+been clearly understood, but since no one brought it to the table then,
+it is too late now.
+
+Ada 95 is not under construction! We are talking about features that have
+been available to users for four years, following a standard that has been
+available for over two years.
+
+From baker Fri Apr 10 08:05:59 1998
+To: dewar@gnat.com
+Subject: RE: AI95-00085
+Content-Length: 600
+
+| I never saw an explicit request for Append mode for Stream_IO ...
+| Ted, can you give the exact reference, I dug a little, but could not
+| find anything at all.
+
+I'm sorry I don't have the original (foot-think) revision requests
+any more, due to lack of storage space.  If you have the original
+revision requests documents on-line, and can't find it there, then
+I may have to partially concede that I remember it wrong.  Of
+course my memory is weighted toward what was said at the
+requirements workshops (e.g. Soderfors and Ft. Walton Beach), and
+that is not written down anywhere to check.
+
+--Ted
+
+From dewar@gnat.com Fri Apr 10 12:29 EST 1998
+Return-Path: <dewar@gnat.com>
+Received: from nile.gnat.com by dad.cs.fsu.edu with SMTP (SMI-8.6/SMI-SVR4)
+	id MAA20879; Fri, 10 Apr 1998 12:29:48 GMT
+Received: by nile.gnat.com (5.0/1.20)
+	id AA22843; Fri, 10 Apr 98 08:27:35 EDT
+Date: Fri, 10 Apr 98 08:27:35 EDT
+From: dewar@gnat.com (Robert Dewar)
+Message-Id: <9804101227.AA22843@nile.gnat.com>
+To: baker@dad.cs.fsu.edu, dewar@gnat.com
+Subject: RE: AI95-00085
+Content-Type: text
+Content-Length: 3415
+Status: R
+
+<<I'm sorry I don't have the original (foot-think) revision requests
+any more, due to lack of storage space.  If you have the original
+revision requests documents on-line, and can't find it there, then
+I may have to partially concede that I remember it wrong.  Of
+course my memory is weighted toward what was said at the
+requirements workshops (e.g. Soderfors and Ft. Walton Beach), and
+that is not written down anywhere to check.
+>>
+
+I was at Soderfors and at Ft. Walton Beach, and I am 99% sure that the
+syncrhonization issue was never mentioned.
+
+I think what happened is that people just *assumed* that the Ada append
+mode would map into the Unix append mode, and so it was not discussed.
+
+I must say I made this same assumption. It was a surprise to find out
+that this was not the case, but I only noticed this later on when I
+came to implement it.
+
+Interestingly, in GNAT, we do not even use append mode for the Text_IO
+and Sequential_IO cases, because of orthogonality in the implementation
+for the Stream_IO case. That's probably undesirable, but actually until
+this discussion, I was completely unaware of the synchronization issue,
+and of course it is completely outside the Ada 95 semantics.
+
+Indeed, relying on Append_File mapping into the Unix mode append even
+for Text_IO or Sequential_IO is incorrect implementation dependent
+coding in any case, so it is not clear that a user should rely on it.
+
+In the GNAT documentation (I am not talking the sources now, but the user
+level documentation), things are quite clear:
+
+Table 6-1 Open and Create Call Modes
+
+                               OPEN           CREATE
+Append_File                    "r+"             "w+"
+In_File                        "r"              "w+"
+Out_File (Direct_IO)           "r+"             "w"
+Out_File (all other cases)     "w"              "w"
+Inout_File                     "r+"             "w+"
+
+If text file translation is required, then either b or t
+is added to the mode, depending on the setting of Text. Text file
+translation refers to the mapping of CR/LF sequences in an external file
+to LF characters internally. This mapping only occurs in DOS and
+DOS-like systems, and is not relevant to other systems.
+
+A special case occurs with Stream_IO. As shown in the above table, the
+file is initially opened in r or w mode for the
+In_File and Out_File cases. If a Set_Mode operation
+subsequently requires switching from reading to writing or vice-versa,
+then the file is reopened in r+ mode to permit the required operation.
+
+I think it is quite important to provide this kind of documentation. Note
+that it is quite clear from this that we do NOT use the a or a+ modes for
+Append_File, and as I said before, no user has ever questioned this
+decision. I can't say all our users read the documentation carefully,
+but I can say that a lot do. 
+
+GNAT does provide a mechanism for opening a Text_IO or Sequential_IO
+file using a stream value obtained from a C library call (or C code
+making such a library call), and so this is the well defined mechanism
+in GNAT for making use of the Unix append modes (you will then of course
+get an exception if you try to do a positioning operation). I would assume
+that any of our customers needing the special synchronization mechanisms
+of Unix/Posix are using this approach, which seems quite appropriate, since
+it nicely encapsulates the implementation dependent part of the process.
+
+From baker Fri Apr 10 09:02:32 1998
+To: dewar@gnat.com
+Subject: Re: AI95-00085
+Content-Length: 771
+
+| That is completely incorrect. Implementing append by changing the current
+| semantics, which our customers have been using for four years is not at
+| all trivial. We will have to do a survey to see who would be affected,
+| and most probably implement some complex mechanism to provide back
+| compatibility to those who are affected.
+...
+| Ada 95 is not under construction! We are talking about features that have
+| been available to users for four years, following a standard that has been
+| available for over two years.
+
+I may have lost the thread by now, but I thought the AI came
+because an implementation was raising Use_Error in this situation,
+and that I've been trying to support the position that such an
+implementation be allowed to continue to do so.
+
+--Ted
+
+From baker Fri Apr 10 09:08:54 1998
+To: dewar@gnat.com
+Subject: RE: AI95-00085
+Content-Length: 610
+
+| this discussion, I was completely unaware of the synchronization issue,
+| and of course it is completely outside the Ada 95 semantics.
+
+It is not exactly synchronization (between processes), but
+atomicity.  All individual I/O operations are atomic up to some
+level of granularity defined by the OS (usually one disk block).
+The special issue here is atomicity of the combined seek-to-end +
+write.  With append mode, you do get something you cannot do with
+the combination of lseek and write.
+
+In this regard, the UNIX kind of append mode also provides
+functionality beyond Ada's Direct_IO interfaces.
+
+--Ted
+
+From dewar@gnat.com Fri Apr 10 12:53 EST 1998
+Return-Path: <dewar@gnat.com>
+Received: from nile.gnat.com by dad.cs.fsu.edu with SMTP (SMI-8.6/SMI-SVR4)
+	id MAA20939; Fri, 10 Apr 1998 12:53:39 GMT
+Received: by nile.gnat.com (5.0/1.20)
+	id AA23135; Fri, 10 Apr 98 08:51:27 EDT
+Date: Fri, 10 Apr 98 08:51:27 EDT
+From: dewar@gnat.com (Robert Dewar)
+Message-Id: <9804101251.AA23135@nile.gnat.com>
+To: baker@dad.cs.fsu.edu
+Subject: RE: AI95-00085
+Content-Type: text
+Content-Length: 338
+Status: R
+
+Ted, is it really the case that my last few messages on this went only to
+you. If so that's really aggravating, since the whole point is to discuss
+this with the ARG.
+
+GRRRR! I see that is the case. Have you saved these messages, if so, PLEASE
+forward them to the whole group. It is really a waste of time for just the
+two of us to talk.
+
+From baker Fri Apr 10 09:12:14 1998
+To: dewar@gnat.com
+Subject: Re: previous mail
+Content-Length: 213
+
+I'll find the mail, and forward it.  I hope it does not overwhelm
+everybody.  I was getting uncomfortable about the volume and length
+of it, hence my limiting my reply to you only, a couple of cycles
+back.  --Ted
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Friday, April 10, 1998 8:43 AM
+Subject: 	Re: last message of Baker/Dewar exchange
+
+| <<I may have lost the thread by now, but I thought the AI came
+| because an implementation was raising Use_Error in this situation,
+| and that I've been trying to support the position that such an
+| implementation be allowed to continue to do so.
+| >>
+
+| Indeed, there is an implementation that wants to negate the standard by
+| raising Use_Error for all uses of positioning when Append_File is used.
+
+| We object because it is perfectly possible, even on Unix, and even if you
+| use the Unix append mode, to support positioning (by reopening the file).
+
+My disagreement here is that if you do this you hide a significant
+semantic event that the user did not expect (i.e., closing and
+then reopening) and which may have unwanted side-effects.
+
+If there were some important special Ada functionality here, this
+might be worth while, but no one has given any argument yet that
+explains how this functionality is needed.  First of all, if
+repositioning is needed (even in other modes) with Stream_IO, why
+can we do without it for Text_IO and Sequential_IO?  Second, if
+the semantics of repositioning in Append mode are the same as a
+combination of other operations that a user could have done, why
+do we need this mode at all?
+
+| But the suggestion that ALL implementations be required to raise Use_Error
+| (your suggestion) is way out of line.
+
+That is *not* what I'm suggesting.  I'm suggesting that implementations
+be allowed (by the ARG) to raise Use_Error.
+
+What may have misled you is that I've also argued that other
+standards groups, like POSIX, be allowed (by the ARG) to narrow
+the semantic window for a particular OS.
+
+--Ted
+
+****************************************************************
+
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 9:20 AM
+To: 	Arg95@sw-eng.falls-church.va.us; baker@dad.cs.fsu.edu
+Subject: 	Re: last message of Baker/Dewar exchange
+
+<<My disagreement here is that if you do this you hide a significant
+semantic event that the user did not expect (i.e., closing and
+then reopening) and which may have unwanted side-effects.
+>>
+
+But these implicit reopens are part of life anyway, you have no way of
+avoiding these for the switch from reading to writing in a stream file,
+you certainly don't want to open all files in update mode just in case
+you may want to write, since that would mean you could not use stream_io
+on read only files.
+
+<<If there were some important special Ada functionality here, this
+might be worth while, but no one has given any argument yet that
+explains how this functionality is needed.  First of all, if
+repositioning is needed (even in other modes) with Stream_IO, why
+can we do without it for Text_IO and Sequential_IO?  Second, if
+the semantics of repositioning in Append mode are the same as a
+combination of other operations that a user could have done, why
+do we need this mode at all?
+>>
+
+It is VERY useful to be able to reposition for stream files, code does 
+this ALL the time. Sequential_IO and Text_IO are at a higher level where
+repositioning makes zero sense.
+
+
+<<| But the suggestion that ALL implementations be required to raise Use_Error
+| (your suggestion) is way out of line.
+
+That is *not* what I'm suggesting.  I'm suggesting that implementations
+be allowed (by the ARG) to raise Use_Error.
+>>
+
+
+No, you are clearly suggesting this, *so that* you can then have the Posix
+binding require its use, so your ultimate agenda is precisely to require
+implementations to raise Use_Error. If this is not your intent (in the long
+run, including what you want the Posix interface to do), please clarify.
+
+To me, introducing implementation dependence here is a bad thing. Both in
+the case of direct Ada use of Stream_IO and the POSIX interface (which
+should support O_APPEND), I see no advantages in introducing implementation
+dependence.
+
+****************************************************************
+
+From: 	David Emery[SMTP:emery@mitre.org]
+Sent: 	Friday, April 10, 1998 9:00 AM
+Subject: 	Re: last message of Baker/Dewar exchange
+
+Well, since my name was mentioned, I guess I'm entitled to contribute $.02 :-)
+
+Ted's recollection about 'intent' for Append_Mode matches my own.  This was
+discussed within the POSIX.5 group, within the SIGAda ALIWG, and in some
+emails
+I remember back and forth during the Mapping and Revision process.  
+
+The particular "desire" was to provide access to the functionality provided
+by Unix's
+O_APPEND for Ada files.  There were two motivations for this:
+	1.  Conformity with Unix semantics
+	2.  It's generally useful.
+Within Unix, the 'formal semantics' mention atomic writes to the end of the
+file.  At the
+user level, this degree of specification wasn't mentioned to my
+recollection.  But the
+"semantics by analogy" from users was clear:  We want Ada's Append_Mode to act
+like Unix's O_APPEND.  
+
+I don't have my copy of POSIX.1 with me (I'm now working nearly full-time
+in the 
+Pentagon :-(, so I can't look at the POSIX-specified for O_APPEND and
+lseek().  
+
+Robert Dewar argues, rightly, for surveying the vendors to see the degree
+of implementation
+approaches. At the same time, it is appropriate in an issue like this to
+survey users, too.
+Thus a message to comp.lang.ada and/or TeamAda that asks people about what
+they
+expect when they use Append_Mode would seem to me to be appropriate.
+
+Personally, I've never thought about the interactions between Append_Mode and 
+file positioning, because my expected use for Append_Mode has always been for
+"write-only" files (e.g. logfiles), where file seeking makes no
+application-level sense.  
+
+				dave
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 9:31 AM
+Subject: 	Re: last message of Baker/Dewar exchange
+
+<<Robert Dewar argues, rightly, for surveying the vendors to see the degree
+of implementation
+approaches. At the same time, it is appropriate in an issue like this to
+survey users, too.
+Thus a message to comp.lang.ada and/or TeamAda that asks people about what
+they
+expect when they use Append_Mode would seem to me to be appropriate.
+
+>>
+
+We can get any answer we like here:
+
+
+What do you think Append_File should do? Most people will simply answer
+that it should start writing at the end of the file.
+
+Do you think Append_File should map to the Unix append mode? Most people
+will simply answer yes.
+
+
+<<Personally, I've never thought about the interactions between Append_Mode and
+file positioning, because my expected use for Append_Mode has always been for
+"write-only" files (e.g. logfiles), where file seeking makes no
+application-level sense.
+>>
+
+So for you, the obvious implementation which Ted rejects would be fine.
+
+The issue is the following.
+
+
+Suppose you open a file in append mode and write some stuff
+
+Then suppose you do a positioning operation.
+
+
+Ted thinks it is fine to reject all positioning operations.
+
+Robert thinks it is easy enough to implement them, so you should.
+
+Ted doesn't like Robert's implementation because it involves closing and
+opening the file, he prefers to be able to completely forbid the positioning.
+
+The trouble is that the RM absolutely clearly and unambiguously, and
+intentionally, allows positioning and append_file mode to be combined.
+
+
+What Ted (and Dave perhaps) are recommending is that implementations be free
+to say
+
+"I could implement that, in a manner consistent with Ada semantics, but I
+don't think it's a good idea, and I would never use it, so I am not going
+to implement it."
+
+That's a heavy burden to support!
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 9:34 AM
+Subject: 	Re: last message of Baker/Dewar exchange
+
+<<I noticed just now that I forgot to add the other main problem,
+i.e., that if you reposition you are no longer appending.  In effect,
+you have changed modes.
+>>
+
+But appending only had to do with the initial position, as Ada is defined.
+Yes, you are certainly not appending in the Unix sense, but you know that,
+because the Unix sense of appending would not have allowed you to position.
+
+
+Actually I think one sense in which positioning and append are perfectly
+compatible from a conceptual point of view is if you are allowed to position,
+but only at or after the original append point. I hoped to be able to read
+this permission into the RM, since it seems to make a lot more sense, but
+in fact I concluded that it was absolutely clear that the RM requires you
+to be able to position behind the starting position, which I agree is bogus.
+
+I really think it would be useful to know what other compilers are 
+currently doing, can we have some data on this please?
+
+****************************************************************
+
+From: 	Robert I. Eachus[SMTP:eachus@mitre.org]
+Sent: 	Friday, April 10, 1998 10:40 AM
+Subject: 	Re: AI95-00085
+
+At 09:30 AM 4/10/98 -0400, Robert Dewar wrote:
+
+> Indeed, there is an implementation that wants to negate the standard by
+> raising Use_Error for all uses of positioning when Append_File is used.
+>
+> We object because it is perfectly possible, even on Unix, and even if you
+> use the Unix append mode, to support positioning (by reopening the file).
+>
+> But the suggestion that ALL implementations be required to raise Use_Error
+> (your suggestion) is way out of line.
+
+    Can we all agree to this?  It allows both sides to go away happy.  Yes,
+it does require a bit of extra work if the implementation chooses to make
+use of O_APPEND.  And, yes, there are cases where the reopening can be
+detected or will fail.  But it preserves the current RM semantics, and will
+allow implementations (including GNAT) to use O_APPEND if they choose to.
+
+    A little more on what happens with the reopen.  It is perfectly
+reasonable for an implementation (IMHO) to raise Use_Error in some cases
+(see A.12.1(33)) --repositioning on a pipe for example.  But in general, an
+implementation must support repositioning on a stream connected to a "real"
+disk file, no matter what mode it was originally opened in.  And there some
+are anomalies that should be left as implementation defined.  (For example,
+if the file is deleted by one task while a second task is writing to the
+associated stream.)
+
+                                        Robert I. Eachus
+
+with Standard_Disclaimer;
+use  Standard_Disclaimer;
+function Message (Text: in Clever_Ideas) return Better_Ideas is...
+
+****************************************************************
+
+From: 	Pascal Leroy[SMTP:phl@Rational.Com]
+Sent: 	Tuesday, April 14, 1998 6:15 AM
+Subject: 	Re: copy of Baker/Dewar exchange
+
+> By the way, what does the ANSI C standard have to say about appending
+> exactly, can someone provide the quote. I think compatibility with C,
+> as opposed to compatibility with Unix, always provides a stronger
+> form of the compatibility argument.
+
+The only interesting thing that I could find in the ANSI C RM is this:
+
+<<7.9.7.3 The fputc function
+
+If the file cannot support positioning requests, or if the stream was opened
+with append mode, the character is appended to the output stream.>>
+
+This is rather terse, but still much more precise than RM95 A.12.
+
+To summarize the ANSI C semantics is as follows:
+
+Positioning is supported for files opened in append mode (except of course for
+some special files, in an implementation-dependent manner).  Positioning is in
+fact _useful_ if the file is opened in a+ or ab+ mode (reading and appending)
+because you can go back to some earlier location in the file, and start
+reading from there.  However, each time you _write_ to the file, you go to the
+end.
+
+As already noted, it is rather unfortunate that Ada doesn't have read+write or
+read+append modes.
+
+If we wanted to mimic the C semantics, we would have to decide that Set_Index
+moves the index (and does not raise an exception); and that the next Write
+moves to the end of file no matter what.  (I am not saying that we should do
+that, btw.)
+
+Pascal
+
+_____________________________________________________________________
+Pascal Leroy                                    +33.1.30.12.09.68
+pleroy@rational.com                             +33.1.30.12.09.66 FAX
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Tuesday, April 14, 1998 5:24 AM
+Subject: 	Re: copy of Baker/Dewar exchange
+
+So one interesting conclusion from Pascal's summary of the ANSI C semantics
+is that forbidding all positioning for stream files in append mode, as
+suggested by some, would actually *decrease* compatibility with C, 
+interesting ...
+
+Pity no one looked at the ANSI C standard more carefully if people think
+that compatibility with C is so important (I don't, my feeling is that
+if you want compatibiliy with C, please use the C routines directly,
+you can still us the stream attributes, so you don't lose any expressive
+power).
+
+****************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Tuesday, April 14, 1998 7:53 AM
+Subject: 	Re: copy of Baker/Dewar exchange
+
+| So one interesting conclusion from Pascal's summary of the ANSI C semantics
+| is that forbidding all positioning for stream files in append mode, as
+| suggested by some, would actually *decrease* compatibility with C, 
+
+It would be compatible. Given that you can't read from an Ada file
+in append mode, the only use of such files is to write.  In C
+repositioning in append mode has no effect on subsequent writes
+(they still go to the end of the file), you effectively cannot
+reposition.
+
+Of course, I agree that it would have been nicer if we had all
+sensible combinations of read, write, append in Ada, but we don't.
+
+| Pity no one looked at the ANSI C standard more carefully if people think
+| that compatibility with C is so important (I don't, my feeling is that
+| if you want compatibiliy with C, please use the C routines directly,
+| you can still us the stream attributes, so you don't lose any expressive
+| power).
+
+Admittedly, the only way to get true C compabibility.
+
+--Ted
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent