[Bug stdio/18990] New: fopencookie broken w.r.t seek within buffered range

[Bug stdio/18990] New: fopencookie broken w.r.t seek within buffered range

[luoqi.chen at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18990

            Bug ID: 18990
           Summary: fopencookie broken w.r.t seek within buffered range
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: critical
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: luoqi.chen at gmail dot com
  Target Milestone: ---

The culprit is the _IO_cookie_seekoff() method, which invalidates the
fp->_offset before performing an actual seek. After fp->_offset is invalidated,
there's no way for the underlying seek algorithm (_IO_new_file_seekoff) to
determine if any part of the buffered data is reusable. This destruction of
buffered data effectively renders fopencookie() useless, except for the
simplest sequential access scenario.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/18990] fopencookie broken w.r.t seek within buffered range

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18990

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Can you provide a test case?  It is not clear to me how changing *internal*
FILE object data in this way would negatively impact the behavior of
user-supplied callbacks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/18990] fopencookie broken w.r.t seek within buffered range

[luoqi.chen at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18990

--- Comment #2 from luoqi.chen at gmail dot com ---
Created attachment 8685
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8685&action=edit
Test case demonstrating the problem

Compile with -std=c99, then run it. The output would look like

read 4096 bytes at 0
seeking to 4096 ... new offset 4096
read 8192 bytes at 0
seeking to 4096 ... new offset 4096
read 8192 bytes at 0
seeking to 4096 ... new offset 4096

that is, seek to the current position *will* trigger an io.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/18990] fopencookie broken w.r.t seek within buffered range

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18990

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
As far as I can tell, this is just a performance issue; the read callback is
invoked unnecessarily.  Do you agree?  It's still a bug, but not a correctness
issue as such.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/18990] fopencookie broken w.r.t seek within buffered range

[luoqi.chen at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18990

--- Comment #4 from luoqi.chen at gmail dot com ---
Agreed on the correctness. A stdio stream provides two functionalities: 1, a
standard streaming interface, 2, a buffering layer. I would say a broken
buffering implementation is serious deficit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/18990] fopencookie broken w.r.t seek within buffered range

[luoqi.chen at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18990

--- Comment #5 from luoqi.chen at gmail dot com ---
A somewhat similar problem we also discovered is with an fopencookie() output
stream, any ftell() call *will* always trigger a flush. Again not a correctness
issue in the narrowest sense, but otherwise still a bug seriously affecting
performance.

-- 
You are receiving this mail because:
You are on the CC list for the bug.