NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/std/c/2373

Internet Message Format | 1992-07-28 | 2.3 KB

Path: sparky!uunet!usc!sdd.hp.com!hplabs!ucbvax!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
From: [e-mail] (Chris Torek)
Newsgroups: comp.std.c
Subject: does "always append" apply to "a+" mode?
Message-ID: <[e-mail]>
Date: 28 Jul 92 20:04:27 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 39
NNTP-Posting-Host: 128.3.112.15

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. ...

    When a file is opened with update mode (|'+'| as the second or
    third character in the above list of |mode| argument values), both
    input and output may be performed on the associated stream.
    However, [switching directions requires an intervening reposition
    or flush or EOF].

To me, it seems clear that a stream opened in "a+" mode can be read at
any arbitrary position, but all writes to that stream are appended to
the underlying file.  There is some dissent, however, on the grounds
that the second paragraph `overrides' the first, i.e., that the first
paragraph does not apply because of the '+' character.

As I understand it, the seek/flush/EOF requirement for direction-
changing is a direct result of existing Unix (and possibly other)
implementations, where an intervening seek is required to `sync up'
internal counters and set a read/write stream's mode to
`indeterminate', so that the next getc or putc macro will trigger a
function call, where the new direction will be set.  It is not meant
to imply that seeks have any effect on "a+" mode files.

Is this correct?  A number of existing implementations that claim POSIX
conformance (and hence ANSI X3.159-1989 conformance) do NOT always
append with "a+" mode; are they broken?

(As an aside, I have an existence proof that the intermediate seek
`feature' is unnecessary, in the form of the 4.3BSD-net.2 stdio.  My
stdio will never allow a getc or putc on an open write- or read-only
stream, whether or not the counters are `synced up'.  All it takes is
two counters, instead of one....)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE ([phone])
Berkeley, CA        Domain:    [e-mail]