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

[Joerg Sonnenberger]

On Wed, Jul 25, 2007 at 06:27:26AM -0600, Eric Blake wrote:
> -----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:

Above is a quote from fflush from SUSv3. But let us talk about fseeko as
that is what is the real problem (and the desire to replace it). There's
also the RATIONALE in fflush that explicitly talks about the writing.

> "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()."

Given that fflush has to defined meaning for read descriptors, this does
not apply (yet). Doing this for buffered reads is bogus as it makes a
lot of optimisations impossible and effectively means that quite a slow
down. I'm not sure whether it is really intentional.

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

This forces fseeko to always do a system call and makes it impossible to
read earlier parts for more efficient buffering. *sigh*

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

OK, so the desired result is that equivalent of
int main(void)
{
        getchar();
        fflush(stdin);
        fseeko(f, 0, SEEK_CUR);
        return 0;
}

effectively changes the position by one? That leaves the question
whether the much less intrusive:
        off_t cur_pos;
        cur_pos = ftello(stdio);
        lseek(fileno(stdin), cur_pos, SEEK_SET);
isn't a much better solution? I can't think of any stdio implementation
where that would not work in contrast to the approach taken here.

Joerg