Re: Plea for clarification on bz #12724

[Csaba Henk]

On Wed, Jul 27, 2011 at 02:58:08PM -0600, Eric Blake wrote:
> > On 07/27/2011 09:31 AM, Csaba Henk wrote:
[...]
> | At page 805 line 26801 section fclose, change:
> |
> |      the file offset of the underlying open file description shall be
> |      adjusted so that the next operation on the open file description
> |      deals with the byte after the last one read from or written to the
> |      stream being closed.
> |
> | to:
> |
> |      the file offset of the underlying open file description shall be
> |      set to the file position of the stream.
> 
> >
> >The text speaks of "_the_ last one [byte] read from or written to
> >the stream". That's a definite article, thus it presupposes existence.
> >So, as I interpret, no definitive statement is here about the case
> >when there was no read or write done on the stream during its lifetime.
> 
> Notice that the new wording does not mention the last byte read at
> all, but rather focuses solely on stream position.
[...]
> >   assert(lseek(fd, 4, SEEK_SET) == 4);
> >   assert (fclose (f) == 0);
> >   errno = 0;
> >   assert (lseek (fd2, 0, SEEK_CUR) == -1);
> >   assert (errno == EBADF);
> >   assert (lseek (fd, 0, SEEK_CUR) == 1);
> 
> That's a bug in your test program.  The latest POSIX wording
> requires the offset of fd to be 4 (because the fclose changed the
> offset of fd2 to be 4).  Once you fix that line of code (in both
> places, read and write streams), then Solaris passes once again,
> which goes to prove that glibc still has a bug in this area.

- A slight objection: my program is not buggy! Its objective was
  to assert glibc 2.14 like behavior and not to assert standard
  compliant behavior (given that of the two, the first being
  well-defined (to me), that what seems to make sense)...
  It demonstrates the difference between glibc 2.14 and Solaris
  libc fclose(3) implementations. Those assertions are technical
  and free of a value judgement. You could call it buggy if you
  were seeing it crash on glibc 2.14.

  But OK, beyond nitpick, I get your point, ie. that the correct,
  standard-compliant  behavior is that of Solaris, ie. the one
  which is against my code's assertion.

- 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));
   assert (fclose (f) == 0);
   errno = 0;
   assert (lseek (fd2, 0, SEEK_CUR) == -1);
@@ -41,7 +43,9 @@ main (void)
   assert (0 <= fd2);
   f = fdopen (fd2, "r");
   assert (f);
+  printf("%ld\n", ftell(f));
   assert(lseek(fd, 4, SEEK_SET) == 4);
+  printf("%ld\n", ftell(f));
   assert (fclose (f) == 0);
   errno = 0;
   assert (lseek (fd2, 0, SEEK_CUR) == -1);

  Output on glibc 2.14:
1
1
1
1

  Output on Solaris:

1
4
Assertion failed: lseek (fd, 0, SEEK_CUR) == 1, file ftesty.c, line 39
Abort (core dumped)

  So it seems, _both_ exhibit the behavior of syncing the file offset to
  the stream's file position on fclose, in accord to the latest
  POSIX definition of fclose. Where they differ is that how they
  implement the concept of "file position"[*] -- with glibc, file
  position is not affected by doing a direct lseek(SEEK_SET)
  on a file descriptor; with Solaris, file position is
  synced to the file offset resulting from the lseek.

  Thus the problem boils down to: what is correct, let a file
  offset change imply an implicit change in the file position, or not? 


,--------------
|[*] that said, POSIX.1-2008 is not-so-consistent in its wording
|of ftell too: in "Name" section it says
|
|  "ftell, ftello - return a file offset in a stream",
|
|in Description,
|
|  "The ftell() function shall obtain the current value of the
|  file-position indicator for the stream"
|
|so it mixes the usage of "file offset" and "file-position"
|which is slightly confusing (although ftell as such is
|a clear thing, being in ISO C...).
`------------

Regards,
Csaba