popen bugs

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Tue Aug 18 14:45:00 GMT 2009


On Tue, Aug 18, 2009 at 08:36:04AM -0600, Eric Blake wrote:
>According to Christopher Faylor on 8/17/2009 5:02 PM:
>> On Mon, Aug 17, 2009 at 03:45:23PM -0700, Eric Blake wrote:
>>> popen misbehaves when various std fds are closed.
>> 
>> And, who among us could have not seen that coming?
>
>I see you fixed the fd access from within child processes in CVS; thanks.
> However, there is still a bug: POSIX requires that children of subsequent
>popen's no longer see the fd of the first popen, without regards to
>FD_CLOEXEC.  Testing on FreeBSD, Solaris, and Linux show that these OS's
>leave the parent's fd as non-cloexec, but still obey this requirement.
>So, they must do it by maintaining a list of fd's opened by popen, and
>explicitly close everything in that list when calling popen again.  And at
>least the newlib implementation (which probably stems from the BSD
>implementation) already has to maintain this list for making pclose work
>correctly.
>
>Cygwin is not compatible with Linux in this regard, because it is relying
>on marking the fd as cloexec, and an explicit call to remove the cloexec
>flag will leak the fd of the first child into the second popen contrary to
>POSIX.  (And this is probably partly my fault, for implementing it wrong
>in newlib, for which I will be submitting a patch today.)
>
>There's also several extensions to consider: a recent addition to glibc
>allows:
>
>popen (cmd, "re");

I don't think it is worth fixing this for 1.7.1 and, as I've previously stated,
we certainly won't be implementing anything like the "e" for 1.7.1.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list