This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
- However, it seems to me that the cited part of the standard is not sufficient to make a judgement regarding which of glibc 2.14 and Solaris is the standard compliant.
There is a more fundamental semantic difference here.
Let us modify the test code by adding some printfs:
diff -up ftestx.c ftesty.c --- ftestx.c 2011-07-28 10:17:23.001229687 +0300 +++ ftesty.c 2011-07-28 10:01:53.106267361 +0300 @@ -29,7 +29,9 @@ main (void) assert (0<= fd2); f = fdopen (fd2, "w"); assert (f); + printf("%ld\n", ftell(f));
assert(lseek(fd, 4, SEEK_SET) == 4); + printf("%ld\n", ftell(f));
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....
A handle which is a stream is considered to be closed when either an fclose() or freopen() is executed on it (the result of freopen() is a new stream, which cannot be a handle on the same open file description as its previous value), or when the process owning that stream terminates with exit(), abort(), or due to a signal. A file descriptor is closed by close(), _exit(), or the exec functions when FD_CLOEXEC is set on that file descriptor.
For a handle to become the active handle, the application shall ensure that the actions below are performed between the last use of the handle (the current active handle) and the first use of the second handle (the future active handle). The second handle then becomes the active handle. All activity by the application affecting the file offset on the first handle shall be suspended until it again becomes the active file handle. (If a stream function has as an underlying function one that affects the file offset, the stream function shall be considered to affect the file offset.)
For the second handle:
*
If any previous active handle has been used by a function that explicitly changed the file offset, except as required above for the first handle, the application shall perform an lseek() or fseek() (as appropriate to the type of handle) to an appropriate location.
assert (fclose (f) == 0);
Thus the problem boils down to: what is correct, let a file offset change imply an implicit change in the file position, or not?
-- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |