Re: fopen(.., "a") + fseek

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> [...fopen(...,"a"), then fseek...]
>> However the fseek() doesn't fail, it is just mostly useless.
> So, a mostly aimless standards-pedantic question: does the implicit
> seek associated with append mode actually count as a call to a file
> positioning function, allowing one to call fread() followed
> immediately by fwrite()?

"No", I think.  Found in fopen.c (fopen.c,v 1.13, which was current as
of something like 20 hours ago):

        /*
         * When opening in append mode, even though we use O_APPEND,
         * we need to seek to the end so that ftell() gets the right
         * answer.  If the user then alters the seek pointer, or
         * the file extends, this will fail, but there is not much
         * we can do about this.  (We could set __SAPP and check in
         * fseek and ftell.)
         */

> (And, FWIW, I'm pretty sure the historic behavior of stdio is that
> "a" does not necessarily have this behavior; according to old
> security lore you have to open() with O_APPEND if you really want to
> be sure you're appending, e.g. in the presence of multiple writer
> processes.  If you just use fopen and "a" you might get just one seek
> to eof at open time.)

I suspect - and it is just suspicion, based on _very_ fuzzy memory from
the days when I was working with 4.2BSD and 4.3BSD - that this is a
historical artifact, due to a substantial delay between O_APPEND
appearing and fopen(,"a") using it.  (If anyone can refute or support
that suspicion, I'd be interested.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B