Eric Blake wrote:
> 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).
That's mostly irrelevant for Unix-based systems,
so I try not to spend time on it.
However, for now, I do require xfreopen to avoid warnings
about unchecked freopen.
