This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: popen bugs

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]