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

[Joerg Sonnenberger]

On Thu, Jul 26, 2007 at 07:25:23AM -0600, Eric Blake wrote:
> > This would
> > mandate an explicit after the program is executed as well.

                        ^ reread / flushing of cached content

> The second transfer of active handle occurs when the child exits and
> returns control to m4.  Here, the child falls under the same bullet, and
> the act of exiting the child (or if the child does an explicit fflush)
> will set the offset of the fd to the next byte unread by the child.  At
> which point m4 needs do nothing to become the active handle, and should
> pick up where the child left off, with no extra stdio calls required on
> m4's part (that is, if stdio is POSIX compliant).

The missing part above might clarify what I meant. Normally a stdio
implementation is allowed to keep its read buffer even across fseeko.
I don't think the rpl_fseeko changes that as it only modifies the
internal position accordingly. So the example is m4 is called with a
regular file on stdin and the subprogram modifies this file after the
current position. Is m4 expected to see such changes?

There's also the indenpend question whether lseek is the best approach
to find seekability. There were a number of issues with real seeks on
character devices like tapes and I'm not sure how the interactions with
zero seeks are. So an explicit test for a regular file might be the
better idea.

> On a system where m4 and sed both follow POSIX rules, this is an example
> of the above rules (and I use this example in the testsuite for CVS head
> of m4
> http://cvs.savannah.gnu.org/viewvc/m4/tests/others.at?revision=1.35&root=m4&view=markup;
> it is conditionally run after first checking whether sed also obeys POSIX
> rules for seekable stdin):

I understand what it is intended for.

> > If I
> > understand the implications correctly, the only correct approach would
> > be to disable buffering before calling the program and reenable that
> > afterwards. That should be portable as well.
> 
> Nope.  It may work on some systems, but the POSIX specification of setvbuf
> states that it may only safely be used prior to any I/O on the stream.  It
> is not portable to go switching m4's copy of the stream between buffered
> and unbuffered, once m4 has started reading from it, and I am not about to
> make m4 use stdin unbuffered from the getgo.  So that rules out your idea
> of setvbuf.

I don't see such a requirement anywhere, at least not in SUSv3. The BSD
man page correctly annotates that calling setvbuf might flush unread
input, but that is kind of the desired affect here. It leaves the
question whether buffering more than one line at a time is not
conflicting with the file positioning issues.

Joerg