Re: [PATCH] Never cache offset when the stream handle is not active (BZ #16680)

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Mar 11, 2014 at 06:09:35AM +0530, Siddhesh Poyarekar wrote:
> On Mon, Mar 10, 2014 at 02:34:59PM -0400, Rich Felker wrote:
> > Caching the offset is valid when writing in append mode. The one case
> > that's special for append mode is that, even once the handle is
> > active, you can't save the resulting offset at the time of seek/rewind
> > and use it for ftell during subsequent writing. This is because the
> > (first) write after seeking could change the current offset. One easy
> > way to deal with this is to treat seek/rewind as deactivating the
> > handle when the stream is in append mode, but more fine-grained
> > solutions are possible too.
> 
> Treating seek/rewind as deactivating the handle won't help for append
> mode because we want to simulate the file position as being the end of
> file regardless of the file position when the handle is inactive, but

Why do you want to do this? It's wrong. If the handle is inactive, the
only way you can get the position is by calling lseek(fd,0,SEEK_CUR).
This is because operations on another handle could have changed the
position without stdio's knowledge.

> after a seek, the stream is assumed to be in read mode until the next
> write and in such a case, we want to know the actual position of the
> file and not the simulated end-of-file.  That is why I use writing in
> append mode as a coarse-grained indicator that the file offset is the
> end of file.  Isn't it similar to what you do in musl?

In musl there is no caching. ftello calls lseek(fd,0,SEEK_CUR) in all
cases except append mode with unflushed buffer; in this case it calls
lseek(fd,0,SEEK_END). (It's valid to move the offset in this case
because having unflushed data is proof that the handle is active.)

Rich