This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, Mar 10, 2014 at 09:12:04PM +0530, Siddhesh Poyarekar wrote:
> On Mon, Mar 10, 2014 at 11:37:13AM -0400, Rich Felker wrote:
> > On Mon, Mar 10, 2014 at 05:53:06PM +0530, Siddhesh Poyarekar wrote:
> > > Hi,
> > > 
> > > The ftell implementation was made conservative to ensure that
> > > incorrectly cached offsets never affect it.  However, this causes
> > > problems for append mode when a file stream is rewound.
> > > 
> > > For a and a+ mode files in read mode, rewinding the stream should
> > > result in ftell returning 0 as the offset, but without caching, it
> > > just assumes that the file offset is the end of file (as opposed to
> > > SEEK_CUR, since rewind correctly sets it).  Now I couldn't find
> > > anything in POSIX that specifies the stream position after rewind()
> > > for a file opened in 'a' mode, but for 'a+' mode it should be set to
> > > 0.  For 'a' mode too, it probably makes sense to keep it set to 0 in
> > > the interest of retaining old behavior.
> > > 
> > > The best way to fix this would be to avoid caching the offset before
> > > the file handle is active.  With this change, the only time the offset
> > > cache is not reliable is when the file is writing in any of the append
> > > modes.
> > 
> > I'm confused. I thought we discussed before that caching the offset is
> > _always_ invalid when the file handle is not active. This is not
> > specific to append mode.
> 
> Sorry, I should have been specific - the only time the offset cache is
> not reliable in an _active_ file handle is when the file is writing in
> any of the append modes.  The cache is always invalid when the handle
> is not active, which is why no function should cache the offset till
> the handle is activated.  Does that sound correct now?

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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]