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 7:10 AM:
> 
> 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.

The newlib library uses a BSD-based stdio, and manages to optimize in
spite of these restrictions.  Basically, you are only forced to use a
non-optimized seek IF the user does fflush followed by fseek.

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

No, fseeko is only forced to do a system call IF it was immediately
preceeded by fflush (or, the way newlib does it, fflush does the system
call and marks the stream as non-optimized, then fseeko can be a no-op;
all other stdio operations undo the fflush non-optimized mark).

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

Yes.

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

No, because now that the position of the underlying fd does not match the
optimized position that stdin has recorded, any further use of stdin will
be broken.  M4 uses fflush(stdin) immediately before spawning a child
process with the syscmd macro, but when the child is complete, m4 again
uses stdin, so m4 must not do anything that confuses stdin by manipulating
fileno(stdin) behind stdio's back.

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

iD8DBQFGp08o84KuGfSFAYARApOYAKCwpTMU07ulg+aOaHpPn0wQUVaUvwCcCe7q
wJIehLsKoHK20QtTIf8x7/Q=
=9vPm
-----END PGP SIGNATURE-----