Re: more gcc warnings

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 7/15/2005 4:10 PM:
> 
> 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).

With that simplification, here goes a version of rpl_freopen that lets CVS
head work on cygwin.  Of course, this is cygwin-specific; it would need
accompanying autoconf magic and #ifdef'ery to install it only on platforms
with O_BINARY and where freopen(NULL) doesn't work, without causing
compile errors on other platforms.

#include <errno.h>
#include <fcntl.h>
#include <io.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

/* Like freopen, but when NAME is NULL, ensure that it is only used as
   rpl_freopen (NULL, "rb", stdin) or rpl_freopen (NULL, "wb", stdout),
   to force those streams to binary.  Any other MODE or FILE for a NULL
   NAME closes FILE and fails with EBADF.  */

FILE *
rpl_freopen (const char *name, const char *mode, FILE *file)
{
  int fd;
  if (name)
    return freopen (name, mode, file);
  if (! mode)
    {
      errno = EINVAL;
      return NULL;
    }
  fd = fileno (file);
  if ((fd == STDIN_FILENO && ! strcmp (mode, "rb"))
      || (fd == STDOUT_FILENO && ! strcmp (mode, "wb")))
    {
      if (! isatty (fd))
        setmode (fd, O_BINARY);
      return file;
    }
  fclose (file);
  errno = EBADF;
  return NULL;
}

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

I don't know whether DJGPP (the DOS port) uses newlib, or does something
else for freopen, or if it has bit-rotted in enough other places in
coreutils CVS to make it worth worrying about.  If someone is actively
maintaining that port, they will let us know soon enough; otherwise I
don't think it is worth worrying about.  The only problem I see with
ignoring the error is that freopen() is required to close its stream on
error, and that the documentation of fclose() states that operations on a
closed FILE* result in undefined behavior; but you are right that in
general, a closed stream will gracefully cause further errors that will be
detected by the existing code rather than crashing the system.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC2Q8Q84KuGfSFAYARAo3YAJ95iMsv08tM6w+W+IyeMAwj3/01YACghLwJ
gkS3P7rCQfVpKC+cqHPbW5I=
=H7xC
-----END PGP SIGNATURE-----