This is the mail archive of the glibc-bugs@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]

[Bug stdio/17063] fclose() may fail to flush data


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.

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