bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fflush after ungetc


From: Eric Blake
Subject: Re: fflush after ungetc
Date: Wed, 26 Mar 2008 13:19:53 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

-----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 <address@hidden> 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             address@hidden
-----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-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]