Re: [1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag

[Geoff Clare]

casper@oracle.com  wrote, on 17 Mar 2020:
>
> 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().

It doesn't make any requirement for popen() to support "wf", it just
encourages (in non-normative text) implementations to add it.  It was
done this way because it's invention.

Applications can easily arrange for FD_CLOFORK to be set on a stream by
using open() with O_CLOFORK and then fdopen(), instead of using fopen().
Doing the equivalent of popen() "wf" with lower-level calls is much harder.
So we thought encouraging fopen() "wf" was not justified, but for popen()
it is.  Of course, implementations that add "wf" for popen() may want to
add it to fopen() for consistency (and maybe also "rf" there, but a
proper "rf" for popen() is very hard to implement).  Maybe for Issue 9
there will be enough existing practice to standardise some of this.

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

The resolution of bug 411 currently requires fdopen() with "e" to set
FD_CLOEXEC.  (Without "e" it is required not to change it.)

If specifying "e" does nothing, then there's no point requiring fdopen()
to accept "e".

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

We have no plans to require anything to do with "f" flags in Issue 8.
As I said above, they may be candidates for standardising in Issue 9,
but that will depend on what implementations do.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: [1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag

[Casper . Dik]

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.