🚀 go-pugleaf

In article <13851@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
[In some other article, whose attribution is gone, someone wrote:]
>> In the section on fopen (4.9.5.3, pp. 130--131), the Standard says:
>>     Opening a file with append mode (|'a'| as the first character in
>>     the |mode| argument) causes all subsequent writes to the file to be
>>     forced to the then current end-of-file, regardless of intervening
>>     calls to the |fseek| function. ...

>It has never been clear to me what the model is for "a" mode.
>Is it like Fortran's
>	OPEN(UNIT=..., FILE='name', ACTION='WRITE', POSITION='APPEND')
>(i.e. is it just like "w" mode except for being _initially_ positioned at
>the end of the existing file), or is like like UNIX's
>	open("name", O_WRONLY|O_APPEND|O_CREAT)

From the section of the standard that the original poster copied above, it
seems pretty clear that the intent is to be like O_APPEND.  It specifically
says, "the then current end-of-file", which I believe means "the
end-of-file at the time of any given write".

>    (1)	Assume or ensure that no other process or FILE* refers to the file,
>	and treat it as if it was "w" except for seeking to the end instead
>	of truncating.
>
>    (2)	Assume that other processes _might_ be using the file,
>	explicitly use setvbuf() to make sure the buffer is big enough to
>	hold a complete formatted record, and _religiously_ use fflush()
>	after writing each record (because if I don't do these things,
>	the buffer might fragment my logical formatted record, and the
>	fragments might be interleaved with fragments from another process).

I think this is a separate issue from your initial confusion.  I.e. does
"end-of-file" refer to any cached information that stdio maintains, or does
it always refer to the actual end of the file as maintained by the OS.
Since stdio allows almost arbitrary buffering, I don't think the standard
can make many guarantees about files that are being written by multiple
processes unless you use setvbuf(STREAM, null) to disable buffering
completely, and even then you're limited by the OS's guarantees of
atomicity.

>I appreciate that the ANSI standard cannot and should not make promises
>about UNIX-specific features sucha s O_APPEND; I'm not so much asking
>"can I get access to this feature" as asking "might this feature be used,
>and if so, what damage can that do to me".

It seems obvious to me that "a" mode was intended to map onto O_APPEND mode
on Unix.  But I don't think that stdio is required to flush its buffer
using an atomic write (the OS could use smaller buffers than you've
specified with setvbuf()), so it's conceivable that a record could get
split up if multiple processes are appending to the file simultaneously.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar