[Bug stdio/16680] ftell does not give the correct output for append mode files after a rewind

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  ae42bbc55a9e05976269026ddabcfb917f6e922f (commit)
       via  ea33158c96c53a64402a772186956c1f5cb556ae (commit)
      from  b1dbb426e164ad1236c2c76268e03fec5c7a7bbe (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ae42bbc55a9e05976269026ddabcfb917f6e922f

commit ae42bbc55a9e05976269026ddabcfb917f6e922f
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Mon Mar 17 18:42:53 2014 +0530

    Change offset in fdopen only if setting O_APPEND

    fdopen should only be allowed to change the offset in the file it
    attaches to if it is setting O_APPEND.  If O_APPEND is already set, it
    should not change the state of the handle.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ea33158c96c53a64402a772186956c1f5cb556ae

commit ea33158c96c53a64402a772186956c1f5cb556ae
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Mar 11 17:04:49 2014 +0530

    Fix offset caching for streams and use it for ftell (BZ #16680)

    The ftell implementation was made conservative to ensure that
    incorrectly cached offsets never affect it.  However, this causes
    problems for append mode when a file stream is rewound.  Additionally,
    the 'clever' trick of using stat to get position for append mode files
    caused more problems than it solved and broke old behavior.  I have
    described the various problems that it caused and then finally the
    solution.

    For a and a+ mode files, rewinding the stream should result in ftell
    returning 0 as the offset, but the stat() trick caused it to
    (incorrectly) always return the end of file.  Now I couldn't find
    anything in POSIX that specifies the stream position after rewind()
    for a file opened in 'a' mode, but for 'a+' mode it should be set to
    0.  For 'a' mode too, it probably makes sense to keep it set to 0 in
    the interest of retaining old behavior.

    The initial file position for append mode files is implementation
    defined, so the implementation could either retain the current file
    position or move the position to the end of file.  The earlier ftell
    implementation would move the offset to end of file for append-only
    mode, but retain the old offset for a+ mode.  It would also cache the
    offset (this detail is important).  My patch broke this and would set
    the initial position to end of file for both append modes, thus
    breaking old behavior.  I was ignorant enough to write an incorrect
    test case for it too.

    The Change:

    I have now brought back the behavior of seeking to end of file for
    append-only streams, but with a slight difference.  I don't cache the
    offset though, since we would want ftell to query the current file
    position through lseek while the stream is not active.  Since the
    offset is moved to the end of file, we can rely on the file position
    reported by lseek and we don't need to resort to the stat() nonsense.

    Finally, the cache is always reliable, except when there are unflished
    writes in an append mode stream (i.e. both a and a+).  In the latter
    case, it is safe to just do an lseek to SEEK_END.  The value can be
    safely cached too, since the file handle is already active at this
    point.  Incidentally, this is the only state change we affect in the
    file handle (apart from taking locks of course).

    I have also updated the test case to correct my impression of the
    initial file position for a+ streams to the initial behavior.  I have
    verified that this does not break any existing tests in the testsuite
    and also passes with the new tests.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                        |   19 +++++
 NEWS                             |    4 +-
 libio/fileops.c                  |  102 +++++++++---------------
 libio/iofdopen.c                 |   16 ++++
 libio/tst-ftell-active-handler.c |  167 +++++++++++++++++++++++++++++++++++++-
 libio/wfileops.c                 |   47 ++++++-----
 6 files changed, 261 insertions(+), 94 deletions(-)

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