This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/17063] fclose() may fail to flush data
- From: "ppluzhnikov at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 23 Jun 2014 14:55:53 +0000
- Subject: [Bug stdio/17063] fclose() may fail to flush data
- Auto-submitted: auto-generated
- References: <bug-17063-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17063
Paul Pluzhnikov <ppluzhnikov at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
From: Siddhesh Poyarekar <siddhesh@redhat.com>
---
That's not a bug because you're invoking a behaviour explicitly
forbidden by the standard:
When a file is opened with update mode ( '+' as the second or
third character in the mode argument), both input and output may
be performed on the associated stream. However, the application
shall ensure that output is not directly followed by input without
an intervening call to fflush() or to a file positioning function
( fseek(), fsetpos(), or rewind()), and input is not directly
followed by output without an intervening call to a file
positioning function, unless the input operation encounters
end-of-file.
We forbid it in the manual too:
As you can see, â+â requests a stream that can do both input and
output. When using such a stream, you must call fflush (see Stream
Buffering) or a file positioning function such as fseek (see File
Positioning) when switching from reading to writing or vice
versa. Otherwise, internal buffers might not be emptied properly.
If you add an fseek call before ftello, you'll see the correct
behaviour because fseek acts as the necessary barrier between fread
and fwrite. ftell is not good enough for that because it cannot be
relied on to change fp state.
---
Thanks for analysis.
This is quite end-user unfriendly behavior:
- it's new ("broke" somewhere between glibc-2.15 and 2.19),
- it's "broken" only for some, but not all, calls to output followed by input
without intervening flush.
--
You are receiving this mail because:
You are on the CC list for the bug.