Re: Help with create_pipe_bidi

[Eric Blake]

Akim Demaille <akim <at> lrde.epita.fr> writes:

> Reading the code, I don't see why the child should be affected here,  
> but it is.

It is due to a bug in gnulib.

|  if (pipe_stdin)
|    if (pipe (ofd) < 0
|        || (ofd[1] = fd_safer (ofd[1])) < 0)

This has the effect of setting ofd to {1,5} if exactly one of stdin/stdout were 
closed.  Then, in the child:

| if (pipe_stdin)
|   {
|     close (ofd[0]);
|     close (ofd[1]);
|   }

we blindly closed both descriptors.  This is only safe if BOTH fd's were moved 
past 2, rather than just ofd[1] (a similar bug exists for ifd).  There are 
several possible fixes (such as being more complex with the posix_spawn fd 
manipulation, or making the close of ofd[0] conditional on whether it is a 
standard fd), but I think the simplest is just replacing the existing two calls 
to pipe/fd_safer with the simpler one-line call to pipe_safer.  I'll commit a 
patch later today, which also adds a pipe-test module using your test-pipe.c as 
a starting point (but avoiding the use of m4, which is not guaranteed to be 
available on all client machines of packages using the pipe module).

And this gnulib bug means that m4 has a regression in 1.4.13 (which uses 
create_pipe_in) when compared to 1.4.11 (which used popen) (although in the 
create_pipe_in case, the bug requires closing 2 of the std descriptors, not 
just one as in create_pipe_out or create_pipe_bidi):

$ echo 'esyscmd(echo hi >&2)dnl' > oops.m4
$ m4-1.4.11 <&- >&- oops.m4
hi
$ m4-1.4.13 oops.m4 <&- >&-
/bin/m4: esyscmd subprocess failed
$ echo $?
0

Even worse, m4 1.4.13 isn't setting the exit status to nonzero on this failure.

Looks like I have a reason to release m4 1.4.14 now.

-- 
Eric Blake