This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Move offset to end of file when fdopen is in "a" mode (#16532)
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, libc-alpha at sourceware dot org
- Date: Tue, 11 Feb 2014 11:22:31 +0100
- Subject: Re: [PATCH 1/2] Move offset to end of file when fdopen is in "a" mode (#16532)
- Authentication-results: sourceware.org; auth=none
- References: <20140211083800 dot GB1424 at spoyarek dot pnq dot redhat dot com> <20140211095455 dot GV15627 at brightrain dot aerifal dot cx> <20140211100558 dot GF1424 at spoyarek dot pnq dot redhat dot com>
On Tue, Feb 11, 2014 at 03:35:58PM +0530, Siddhesh Poyarekar wrote:
> On Tue, Feb 11, 2014 at 04:54:55AM -0500, Rich Felker wrote:
> > Are you sure this fixes the issue? I think there are still cases where
> > the wrong offset might be seen. For instance it's legal to call lseek
> > on the fd after calling fdopen (the FILE is not the "active handle"
> > until you read/write with it) and then ftell could still report the
> > wrong result.
>
> It shouldn't make a difference. The only reason to seek to the end is
> to record the offset of the file end into the FILE object. If an
> lseek moves it elsewhere, we don't care. Data will be appended to the
> end of the file in any case since we add an O_APPEND to the fd.
>
How does that handle a+ mode? A offset should be at start but you need
to write at end.
> > We had a similar bug in musl (but not the same; it manifested in more
> > cases than the glibc one) and I fixed it by doing the repositioning at
> > ftello time when the stream is append-mode and there's unwritten
> > buffered data:
> >
> > http://git.musl-libc.org/cgit/musl/commit/?id=3af2edee150484940916eba1984f78c3b965dd05
>
> This is precisely what my earlier ftell optimization avoided whenever
> it could. It is still avoidable for append, but not for append-update
> (a+) at least in the initial case.
>
> Siddhesh