-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Joerg Sonnenberger on 7/25/2007 4:49 AM: >> GNU M4 relies on POSIX behavior in the stdio library in order to comply >> with POSIX requirements on its own behavior. > > To quote SUSv3: > > If stream points to an output stream or an update stream... > If stream is a null pointer, ... > > Using it on an input stream doesn't seem to be POSIX at all. This seems > to be in line with the historic behaviour since C89, but I can't check > that due to lack of the standard document.
You are correct that it is unspecified by C89. However, it IS in SUSv3/POSIX, and m4 relies on it. In POSIX 2001, the wording is obscure; you have to look in fseeko, which states the following, without any restriction on whether the stream is output or input: "If the most recent operation, other than ftell(), on a given stream is fflush(), the file offset in the underlying open file description shall be adjusted to reflect the location specified by fseek()." But the next revision of POSIX (likely to be part of SUSv4), of which the 3rd draft is available to Austin group members (free membership, http://www.opengroup.org/austin/lists.html), makes it more obvious, by adding the following text directly to the fflush() specification with CX shading (and similar wording to fclose(), since it behaves the same as though it calls fflush): "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." The reason this POSIX requirement is important is that POSIX also requires the following behavior: $ echo '1 2 3' > foo $ (sed 1q; cat) < foo 1 2 3 $ (sed -n '1p;2q'; cat) < foo 1 3 In other words, when a file description for a seekable file is shared among multiple processes, the second process must start processing at the position where the first process left off, which implies repositioning the file description of a seekable input stream, which m4 does via fflush/fseeko. > >> If gnulib's approach does not work on DragonFly, you are welcome to patch >> either DragonFly to comply with POSIX, or submit a patch to gnulib so that >> gnulib's approach will work on DragonFly. > > I'm not even sure what gnulib tries to achieve here and I'm certainly > opposing its use of stdio internals. It seems that the existing fpurge > interface *might* be what is desired here, but I am not sure. fpurge is not specified by POSIX. The goal of fflush(stdin) is to make sure that if stdin refers to a seekable file description, that fflush() followed by fseeko(f, 0, SEEK_CUR) will reposition the file description to the next unread character, rather than leaving it positioned at the end of the buffered read, and rather than failing with EBADF. Gnulib uses fpurge to help implement this (since, if a file description is truly seekable, discarding unread data is a first step towards repositioning the file description), but has to also muck with FILE internals on platforms where fpurge is buggy and violates stdio invariants, as well as on platforms that lack fpurge. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----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 iD8DBQFGp0GP84KuGfSFAYARApzSAKCMs55LL0827AkCUAc2LrW19WwOSwCgzwZo 4i4+LUGQjTluT4u+ddzhdUY= =fLcf -----END PGP SIGNATURE-----
