It seems that this bug changes the following commands about a "wf" or "rf"
option for popen(); however, I do not see the additional changes needed
for fopen().
Another question I have is this: in fdopen(), Solaris will NOT change the
file flags even when "e" is given; this makes sense, I think.
So we ignore "e" on fdopen and would do the same for "f"; and I'm assuming
that the future standard will include "f" as the "open the file with
O_CLOFORK" for fopen() and ilk?
Casper
----
On page 1439 line 47807 section popen(), after the bug 411 text:
... any application worried about the potential file descriptor leak will
already be using the e modifier.
add a new paragraph:
Implementations are encouraged to add support for a "wf" mode which creates
the pipe as if by calling pipe2() with the O_CLOFORK flag and then clearing
FD_CLOFORK for the read side of the pipe. This prevents the write side from
leaking into child processes created by other threads, ensuring the child
created by popen() will get end-of-file when the parent closes the write side
(although the read side can still be leaked). Unfortunately there is no way
(short of temporarily preventing other threads from creating child processes,
or implementing an atomic create-pipe-and-fork system call) to implement an
"rf" mode with the equivalent guarantee that the child created by popen() will
be the only writer. Therefore multi-threaded applications that do not have
complete control over process creation cannot rely on getting end-of-file on
the stream and need to use an alternative method of indicating the end of
communications.
