From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17626 invoked by alias); 23 Jun 2014 14:55:59 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 17569 invoked by uid 48); 23 Jun 2014 14:55:55 -0000 From: "ppluzhnikov at google dot com" To: glibc-bugs@sourceware.org Subject: [Bug stdio/17063] fclose() may fail to flush data Date: Mon, 23 Jun 2014 14:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ppluzhnikov at google dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg01387.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17063 Paul Pluzhnikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paul Pluzhnikov --- From: Siddhesh Poyarekar --- 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, =E2=80=98+=E2=80=99 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 inp= ut without intervening flush. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-24012-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jun 23 15:15:23 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 8094 invoked by alias); 23 Jun 2014 15:15:22 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 8059 invoked by uid 48); 23 Jun 2014 15:15:17 -0000 From: "siddhesh at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug stdio/17063] fclose() may fail to flush data Date: Mon, 23 Jun 2014 15:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: siddhesh at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg01388.txt.bz2 Content-length: 799 https://sourceware.org/bugzilla/show_bug.cgi?id=17063 --- Comment #3 from Siddhesh Poyarekar --- (In reply to Paul Pluzhnikov from comment #2) > 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. Yes, it broke when I wrote a new implementation of ftell. The earlier implementation was essentially an alias for fseek (fp, 0, SEEK_CUR), which is why it worked as an intermediate function to switch between reads and writes. I didn't bother versioning the change because we explicitly forbid the behaviour this bug relies on. -- You are receiving this mail because: You are on the CC list for the bug.