casper....@oracle.com <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 <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
