lib/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2025-07-30 22:43:12 +03:00
Code Activity

Use cached offset in ftell when reliable

Browse Source 
The cached offset is reliable to use in ftell when the stream handle
is active.  We can consider a stream as being active when there is
unflushed data.  However, even in this case, we can use the cached
offset only when the stream is not being written to in a+ mode,
because this case may have unflushed data and a stale offset; the
previous read could have sent it off somewhere other than the end of
the file.

There were a couple of adjustments necessary to get this to work.
Firstly, fdopen now ceases to use _IO_attach_fd because it sets the
offset cache to the current file position.  This is not correct
because there could be changes to the file descriptor before the
stream handle is activated, which would not get reflected.

A similar offset caching action is done in _IO_fwide, claiming that
wide streams have 'problems' with the file offsets.  There don't seem
to be any obvious problems with not having the offset cache available,
other than that it will have to be queried in a subsequent
read/write/seek.  I have removed this as well.

The testsuite passes successfully with these changes on x86_64.
This commit is contained in:
Siddhesh Poyarekar
2014-03-04 12:23:27 +05:30
parent 000232b9bc
commit fa3cd24827
5 changed files with 65 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
libio/fileops.c
View File

@ -964,12 +964,8 @@ get_file_offset (_IO_FILE *fp)
static _IO_off64_t
do_ftell (_IO_FILE *fp)
{
_IO_off64_t result;
result = get_file_offset (fp);
if (result == EOF)
return result;
_IO_off64_t result = 0;
bool use_cached_offset = false;
/* No point looking at unflushed data if we haven't allocated buffers
yet. */
@ -983,8 +979,34 @@ do_ftell (_IO_FILE *fp)
result -= fp->_IO_read_end - fp->_IO_read_ptr;
else
result += fp->_IO_write_ptr - fp->_IO_read_end;
/* It is safe to use the cached offset when available if there is
unbuffered data (indicating that the file handle is active) and the
handle is not for a file open in a+ mode. The latter condition is
because there could be a scenario where there is a switch from read
mode to write mode using an fseek to an arbitrary position. In this
case, there would be unbuffered data due to be appended to the end of
the file, but the offset may not necessarily be the end of the
file. It is fine to use the cached offset when the a+ stream is in
read mode though, since the offset is maintained correctly in that
case. Note that this is not a comprehensive set of cases when the
offset is reliable. The offset may be reliable even in some cases
where there is no unflushed input and the handle is active, but it's
just that we don't have a way to identify that condition reliably. */
use_cached_offset = (result != 0 && fp->_offset != _IO_pos_BAD
&& ((fp->_flags & (_IO_IS_APPENDING | _IO_NO_READS))
== (_IO_IS_APPENDING | _IO_NO_READS)
&& was_writing));
}
if (use_cached_offset)
result += fp->_offset;
else
result += get_file_offset (fp);
if (result == EOF)
return result;
if (result < 0)
{
__set_errno (EINVAL);