Re: readpipe patch again

[Paul Eggert]

After looking a bit more at that patch, I see a problem coming up.

The current Bison CVS has a bug: it creates a temporary file to feed
to m4, but it doesn't clean up the file if interrupted.

The simplest way that I can see to fix the problem is to modify Bison
to not create a temporary file at all: instead, Bison can just write
to a pipe and have m4 read from that pipe.

To do this, Bison would create a pipe and then fork.  One subsidiary
process would write to the new pipe.  The other subsidiary process
would exec m4 to read from that pipe.  This would be in addition to
the pipe+fork that Bison already uses to read from the output of m4.

Now, this solution depends on having fork and pipe.  And yet your
proposed patch to readpipe ports Bison to non-GNU hosts that lack a
working fork.  So it appears that your proposed readpipe patch will
make it harder to fix the abovementioned bug in CVS Bison, if we want
to use the technique described above.

Of course we could fix the bug in a different way on hosts that lack
'fork', but this will complicate Bison and make it harder to maintain.

So this raises the question: how important is it to run Bison on hosts
that lack `fork'?  Such hosts are not GNU hosts; nor are they Unix
hosts; nor are they POSIX hosts.  One could argue that a developer
should have access to a GNU or Unix or POSIX host to run Bison on,
even if the rest of the build runs on some other host.