Re: [PATCH v2] Fix offset caching for streams and use it for ftell (BZ #16680)

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Mar 11, 2014 at 06:16:16PM +0530, Siddhesh Poyarekar wrote:
> The Change:
> 
> I have now brought back the behavior of seeking to end of file for
> append-only streams, but with a slight difference.  I don't cache the
> offset though, since we would want ftell to query the current file
> position through lseek while the stream is not active.  Since the
> offset is moved to the end of file, we can rely on the file position
> reported by lseek and we don't need to resort to the stat() nonsense.

Sounds good. While I haven't done a real code review of your patch
(I'm honestly not familiar with glibc's stdio internals and just
looking at them gives me a headache) your description of the behavior
you're implemented sounds correct to me now.

> Finally, the cache is always reliable, except when there are unflished
> writes in an append mode stream (i.e. both a and a+).  In the latter
> case, it is safe to just do an lseek to SEEK_END.  The value can be
> safely cached too, since the file handle is already active at this
> point.  Incidentally, this is the only state change we affect in the
> file handle (apart from taking locks of course).

Caching is valid for append mode with unflushed writes too. The first
time you get in this situation (transitioning from being an inactive
handle or from read mode) you don't have a valid cached offset to use
and you have to lseek to SEEK_END, but after you have a valid cached
offset, you can use it (being the active handle means that it's UB for
anything else to extend the file and change where the next write would
occur).

Of course one consideration is whether real-world programs actually
obey the rules for active handles. I suspect there might be
(especially log-file-related) cases where legacy software expects
append-mode to work with multiple writers all behaving as if they're
the active handle (this has some race conditions that cause
interleaving but "mostly works" historically) so it may be best not to
try to optimize this case heavily anyway.

Rich