Re: readpipe patch again

[Florian Krohm]

On Monday 06 May 2002 03:38, Paul Eggert wrote:
> 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.
>

I wasn't aware of that.

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

Yes, that would be best.

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

Unless someone objects here, I will change the patch to do what you 
described on systems that have a working fork.

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

I adopted what I saw in diffutils (diff3.c) assuming that what I saw
there was The Right Thing.

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

I agree. But, do GNU projects have the freedom to make this judgement call?
I do not know. Or is this something that should be brought up with the 
people who write the GNU coding standards? I looked through those, but 
they are not specific in this regard.

Florian