[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more gcc warnings
From: |
Eric Blake |
Subject: |
Re: more gcc warnings |
Date: |
Sat, 16 Jul 2005 07:43:44 -0600 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
-----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-----
- Re: more gcc warnings, (continued)
Re: more gcc warnings, Eric Blake, 2005/07/09
- Re: more gcc warnings, Paul Eggert, 2005/07/11
- Re: more gcc warnings, Eric Blake, 2005/07/14
- Re: more gcc warnings, Paul Eggert, 2005/07/14
- Re: more gcc warnings, Eric Blake, 2005/07/15
- Re: more gcc warnings, Paul Eggert, 2005/07/15
- Re: more gcc warnings,
Eric Blake <=
- Re: more gcc warnings, Paul Eggert, 2005/07/16