This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] fdopen("a"), O_APPEND and active handles
- From: Rich Felker <dalias at aerifal dot cx>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 19 Feb 2014 11:22:14 -0500
- Subject: Re: [RFC] fdopen("a"), O_APPEND and active handles
- Authentication-results: sourceware.org; auth=none
- References: <20140219104136 dot GU27461 at spoyarek dot pnq dot redhat dot com>
On Wed, Feb 19, 2014 at 04:11:36PM +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> So while thinking over the third iteration of this fix, it occurred to
> be that even the act of adding O_APPEND to a file descriptor through
> fdopen will change the way subsequent write() calls behave, since they
> will suddenly start appending to the file instead of writing at the
> current location. Given the fact that a handle's effect should not
> come into effect till it performs its first offset modifying act
> (i.e. fseek, read, write, etc.), this behaviour seems to be in
> violation of that expectation.
POSIX permits fdopen to set O_APPEND. See the text you seem to have
already found at:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopen.html
"RATIONALE
... Although not explicitly required by this volume of POSIX.1-2008, a
good implementation of append (a) mode would cause the O_APPEND flag
to be set."
Note that it's also conforming not to set O_APPEND at all, and to rely
on the application to have called fdopen with a mode matching the
existing state of the O_APPEND flag. Since an application cannot rely
on any particular behavior if the state of the O_APPEND flag did not
already match, I don't think there's any reason to worry about when
you set it; for correct applications, setting it will be a no-op
anyway.
Rich