bug-gnulib
[Top][All Lists]
Advanced

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

Re: seekable stdin test failure on OS X


From: Eric Blake
Subject: Re: seekable stdin test failure on OS X
Date: Mon, 02 Apr 2007 13:05:24 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 4/2/2007 12:41 PM:
> Ben Pfaff <address@hidden> writes:
> 
>> ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
>> so I'm inclined to agree.
> 
> It's more complicated than that, I'm afraid.
> 
> Here's how I remember it; I haven't checked the actual documents.  In
> the late 1980s the POSIX committee decided that fflush (stdin) should
> flush the input buffer and (on seekable devices) restore the input
> position on the underyling file descriptor to match the position in
> the stream.

I don't have access to the early POSIX wording to verify this, but think
you are right.

>  At some point in the mid-1990s this requirement was
> weakened to be more like (but not exactly like) ISO C89.

This part is true - the current POSIX is silent about whether
fflush(stdin) is supposed to work, but is explicit that fseek() is
supposed to set the position of the underlying fd if it immediately
follows fflush() without any limitation on whether the fflush/fseek pair
is on an input or an output stream.  So indirectly, the fseek requirement
implies that fflush(stdin) is still valid in the current POSIX.

>  However, in
> the latest POSIX it's stronger again, and is more like the late 1980s.

Yes - the current proposed wording adds this explicit C extension shaded
section to fflush:

CX For a stream open for reading, if the file is not already at EOF, and
the file is one capable of seeking, 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 flushed.

> 
> Part of the problem is that this area is so complicated that almost
> nobody other than standards nerds understands the wording.  (And most
> of them probably don't understand it either.....)
> 
> Anyway, for what it's worth I think fflush (stdin) should behave like
> 1988 POSIX and glibc, at least for apps that care about this sort of
> thing.

Which is why I think a gnulib module for fflush is the right thing to do;
where it can call __fpurge under the hood on systems that reject
fflush(stdin).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEVPz84KuGfSFAYARAqQaAKCdhLhuvy3QKcnVHL6mtkk0Yru29wCgwr3t
l6FYhJZN4CrXgtIARCP3+PM=
=W9Qk
-----END PGP SIGNATURE-----




reply via email to

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