Re: [PATCH] xfreopen: new module, from coreutils

[Eric Blake]

Jim Meyering <jim <at> meyering.net> writes:

> 
> I am about to use this from diff, so...
> BTW, changed license from LGPL in coreutils to GPL here, since
> it doesn't make sense to use error-generating code from a library.

xfreopen still doesn't deal with the problem of whether a stream should be 
reopened in append mode (that is, the difference between "w" and "a", based on 
whether O_APPEND is set on the underlying fd).  This has been the source of a 
cygwin-specific patch to coreutils for some time now, and a topic that has 
reoccurred several times on the coreutils mailing list (although I haven't yet 
been concerned about it enough to push it to the top of my TODO list and 
actually write the patch).

Besides, POSIX 2008 added some wording discouraging the use of freopen to 
change binary modes:

| Since implementations are not required to support any stream mode changes
| when the filename argument is NULL, portable applications cannot rely on the
| use of freopen( ) to change the stream mode, and use of this feature is
| discouraged. The feature was originally added to the ISO C standard in order
| to facilitate changing stdin and stdout to binary mode. Since a ’b’ character
| in the mode has no effect on POSIX systems, this use of the feature is
| unnecessary in POSIX applications. However, even though the ’b’ is ignored, a
| successful call to freopen(NULL, "wb", stdout) does have an effect. In
| particular, for regular files it truncates the file and sets the fileposition
| indicator for the stream to the start of the file. It is possible that these
| side-effects are an unintended consequence of the way the feature is
| specified in the ISO/IEC 9899: 1999 standard, but unless or until the ISOC
| standard is changed, applications which successfully call freopen(NULL, "wb",
| stdout) will behave in unexpected ways on conforming systems in situations
| such as:
| { appl file1; appl file2; } > file3
| which will result in file3 containing only the output from the second
| invocation of appl.

Paul Eggert originally tried using freopen(NULL) instead of setmode() in 
coreutils, on the grounds that only the former is standardized; and on the 
grounds that we care about the FILE* but do not have an idea of whether FILE* 
carries more state for binary vs. text than just the O_BINARY flag of the 
underlying fd.  But I am really starting to thing that Paul's move to use 
freopen was the wrong thing to do, and that we should revert back to using the 
binary-io module from gnulib.  All platforms which support a distinction 
between binary and text support setmode(), even if it is not standardized, and 
can use that to select binary mode without the portability hassle of freopen.  
And cygwin goes to great pains to ensure that setmode() on an fd also affects 
the hidden state of all FILE* visiting that fd.

Another idea that I have had is to add a function to binary-io that converts a 
FILE* from text to binary (right now, binary-io is a bit awkward to use because 
it requires an fd rather than a FILE*), without the hassles currently 
associated with portably using freopen(NULL).

-- 
Eric Blake