Mail Archives: cygwin/2009/08/18/10:45:49
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
- Raw text -