Re: more gcc warnings

[Paul Eggert]

Eric Blake <address@hidden> writes:

> If all that changed was the addition or subtraction of O_APPEND,

For coreutils we don't need to worry about this.  We can assume that
if freopen (NULL, ...) is being called, then the call is either
freopen (NULL, "rb", stdin) or freopen (NULL, "wb", stdout).

> On cygwin, fcntl(F_SETFL) currently doesn't change binary vs. text,
> so that requires setmode(O_BINARY) if the mode included 'b', and it
> would be easy to add our !isatty filter here.

Good, that makes it sound easy.

> But because we do not know whether mode "w" would have opened the
> current file in binary or text mode,

Surely we don't need to worry about that.  We can simply invoke
setmode to change the mode to O_BINARY if the file is not a terminal.

> if (O_BINARY)
>   {
>     FILE *tmp = freopen (NULL, "rb", stdin);
>     if (tmp) stdin = tmp;
>   }

No, that won't work: portable code can't assign to stdin.  But I don't
think we need to worry about this if we adopt the solution mentioned
above.

> Even if newlib (the provider of freopen() for both cygwin and mingw)
> updates freopen() to actually implement file access changes where
> possible, we still need to deal with the fact that a failure will
> close the underlying file descriptor.

Is failure still possible under DOS, under the above assumptions?  If
not, then let's not worry about it.  Otherwise, is it OK if we simply
ignore the failure, and let later uses of the stream report an error?

> Hopefully we are safe so long as we limit ourselves to just use
> freopen(NULL, "rb", stdin), freopen(NULL, "wb", stdout), and
> freopen(non_null, any_mode, any_file), as is the current case in CVS.

Yes, that's the basic idea.