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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 11 Feb 2014 15:35:58 +0530
- 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>
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.
> 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