This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/16605] New: Invalid caching of file position in stdio streams
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 19 Feb 2014 05:46:58 +0000
- Subject: [Bug stdio/16605] New: Invalid caching of file position in stdio streams
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16605
Bug ID: 16605
Summary: Invalid caching of file position in stdio streams
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: stdio
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Test case:
#include <stdio.h>
#include <unistd.h>
int main()
{
FILE *f = tmpfile();
printf("%ld\n", ftell(f));
write(fileno(f), "abc", 3);
printf("%ld\n", ftell(f));
}
Expected output:
0
3
glibc output:
0
0
The issue is that glibc is wrongly caching the file position when it does not
have any guarantee that the stdio FILE stream is or will remain the "active
handle" for the open file description (see POSIX XSH 2.5.1 Interaction of File
Descriptors and Standard I/O Streams). While the exact semantics for active
handle are complex (read the cited text), the basic situation is that you can
only guarantee that the FILE remains the active handle once you've started
reading from or writing to it, and up until an operation that allows the
application to switch to a different active handle (a successful seek, explicit
flush, newline-caused flush on line-buffered stream, reaching eof reading,
etc.).
Note that the test case above only shows the issue for writing, but as far as I
can tell it applies equally to reading, and applies to all possible open modes
(read/write/update/append/etc.). I used tmpfile() for convenience but the same
should work with fopen or fdopen.
--
You are receiving this mail because:
You are on the CC list for the bug.