🚀 go-pugleaf

In article <24992@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
> 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.

The dissenters have no ground to stand on. For an a+ mode file, the
second paragraph requires an fseek or similar action between reading
and writing, while the first paragraph says that this fseek will not
alter the effects of the write, which is to EOF.

In other words, the sequence:

    fread
    fseek  /* to anywhere */
    fwrite

will always append to the file. The effect of the second paragraph is
that the sequence:

    fread
    fwrite

has an undefined effect (and Chris knows better than I do what that
means :-).

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

You are 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?

If the implementation claims conformance to "POSIX.1, C Language Binding
(C Standard Language-Dependent System Support)", then the implementation
is broken (but see below).

If the implementation claims conformance to "POSIX.1, C Language Binding
(Common-Usage C Language-Dependent System Support)", then the implementation
is broken unless its Conformance Document clearly describes the
different behaviour.

If the implementation claims conformance to IEEE 1003.1-1988
(_POSIX_VERSION_ == 198808L) then the "C standard" refers to the
1988-05-13 draft (X3J11/88-002). If it claims conformance to ISO/IEC
9945-1:1990 (a.k.a. IEEE 1003.1-1990) (_POSIX_VERSION == 199009L) then
the C standard is ISO/IEC 9899:1990. I don't know if these two differ in
their handling of this case.

> (As an aside, I have an existence proof that the intermediate seek
> `feature' is unnecessary,

Unnecessary for an implementation, perhaps. It is still necessary for
any conforming application.

-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
Fax:   +44 223 462 132 | United Kingdom      |