-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Geoff Clare on 3/26/2008 11:05 AM:
| [I've been meaning to get round to looking into this one for a
| while; sorry it took so long.]
Thanks for a reply. I'd been meaning to ping on this, but your reply beat me.
|
| Eric Blake <[EMAIL PROTECTED]> wrote, on 06 Mar 2008:
|> My concern is that this statement, added by Interp 002, is ambiguous:
|> "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".
|
| I think that in the presence of ungetc() the statement is not ambiguous,
| it is just wrong.
|
| I believe the intention of the statement is that implementations should
| do the equivalent of lseek(fileno(fp), ftello(fp), SEEK_SET). The point
| is to prevent data loss when changing the active handle for an open
| file description to a handle in a different process. Thus if app1
| uses stdio to read from stdin,
|
| { app1; app2; } < file
|
| works as expected without app1 having to do anything special. It just
| reads from stdin and then closes it (explicitly or implicitly).
|
| Now, if app1 is the type of application that performs read-ahead when it
| parses its input, it may well be that the last thing it did is to call
| ungetc() before standard input is closed. In this case the lseek()
| above is still the right thing for the implementation to do, so that
| app2 will read the first byte that was "unwanted" by app1. However,
| that's not what the statement requires. The last byte read by app1
| was the byte that it passed to ungetc(). The ungetc() doesn't change
| history; it changes what is returned by the next read on the stream
| (if any).
|
| Therefore I think we should change the statement so that it says the
| file offset of the underlying open file description is set to the file
| position of the stream.
|
| This conclusion is based solely on considering what happens for a
| change of active file handle, and specifically when the first handle
| is closed by fclose() (or exit()). Now there are two additional
| items to address:
|
| 1. Should the rule for fflush() be the same as for fclose().
| I believe the answer has to be yes. It would be unthinkable for
| fclose(fp) to behave differently from fflush(fp); close(fileno(fp)).
|
| 2. What happens if the active file handle does not change, i.e. there
| is a subsequent read from the same stream? Should fflush()
| discard the pushed-back byte or not? Given that the file offset of
| the underlying open file description has (for the reasons above) been
| set to the file position of the stream, I think fflush() does have to
| discard the pushed-back byte. Otherwise that byte will be read twice
| after the fflush().
Good - your ideas matched mine.
|
| It is too late to get these changes into the drafts now - it will have
| to wait for TC1.
Understandable.
|
|> Does reading the ungetc buffer count as an
|> operation on the open file description, or is the next operation on the
|> open file description deferred until after the ungetc buffer is exhausted?
|
| If the changes I proposed above are made, this won't matter any more,
| but for what it's worth I would say the latter.
Well, at least we now have a direction to move towards for the gnulib
replacements for broken stdio libraries. In terms of Bruno's categories,
your proposal matches his designation 1a+2a (fflush sets file position to
stream position, and discards ungetc data, whether or not ungetc pushed
back the same or a different byte).
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfqodkACgkQ84KuGfSFAYB05gCgg9Ek5/Eoi3sjKJ6l1j85lieH
HSMAnjSNCn9pI3rbr3gOcsLum2654ZR4
=suKh
-----END PGP SIGNATURE-----
