Re: address@hidden: Re: CVS commit: pkgsrc/devel/m4]

[Eric Blake]

-----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             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

iD8DBQFGp0GP84KuGfSFAYARApzSAKCMs55LL0827AkCUAc2LrW19WwOSwCgzwZo
4i4+LUGQjTluT4u+ddzhdUY=
=fLcf
-----END PGP SIGNATURE-----