On 07/28/2011 07:30 AM, Eric Blake wrote:
f = fdopen (fd2, "w");
assert (f);
+ printf("%ld\n", ftell(f));
So far, so good. fdopen() is required to set the stream position to the
same as the underlying fd position, so this should always print 1.
assert(lseek(fd, 4, SEEK_SET) == 4);
+ printf("%ld\n", ftell(f));
Undefined behavior. POSIX states:
The result of function calls involving any one handle (the "active
handle") is defined elsewhere in this volume of POSIX.1-2008, but if
two or more handles are used, and any one of them is a stream, the
application shall ensure that their actions are coordinated as
described below. If this is not done, the result is undefined.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
Your code has two handles (fd and f), you are starting with fd as the
active handle and did a reposition, then switched to an action on f.
The POSIX wording for fclose() effectively requires an fflush(), and
since fflush() is one of the functions that resync's the stream position
back to the fd position as modified by the first handle, before making f
the active handle, I still stand by my analysis that at this point in
the program, the offset of the file description should remain at 4, and
not be reset to 1 (that is, since the transition from the first handle
which set the offset to 4 to the second handle which used fclose() is
clean, the action on the second handle must not corrupt the fd position
back to 1 merely because the FILE* position had not been advanced from
1). Solaris behavior is correct, glibc behavior is buggy.
This topic came up again in today's Austin Group meeting, reaffirming
that Solaris behavior is correct and glibc 2.14 behavior, while fixing
one aspect of fclose, caused an an unintentional regression in another
aspect when compared to 2.13 behavior:
http://austingroupbugs.net/view.php?id=480
http://austingroupbugs.net/view.php?id=87#c895
The latest wording is that with fclose():
the file offset of the underlying open file description shall be set to
the file position of the stream if the stream is the active handle to
the underlying file description.
Rereading section 2.5.1 tells you when a stream can become the active
handle to an underlying file description - only when the previous active
handle has gotten to a sane state (either because the previous handle
was an fd, or because it was a stream but was unbuffered, at eof, or
just flushed), and the new handle does I/O after either ensuring that
the old handle did no additional lseek/fseek or the new handle starts
I/O with an explicit fseek.
That is, fclose() should _not_ call lseek() to the stream position
unless the stream has done any I/O or fseek() which would qualify as
making the stream an active handle, such that the stream position has a
reason to be reflected back into the file description position.
When dealing with multiple handles to a file description, then you must
ensure that you can properly transition from one active handle to
another. As long as the active handle transition rules are defined, then
yes, a file offset change will be observable as an implicit change in
the file position. As soon as the active handle transition rules are
broken (such as calling ftell() without an intervening fflush()), then
This should have read:
such as calling ftell() without an intervening fseek()
behavior is undefined.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
