bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnulib's freopen replacement and MinGW


From: Eric Blake
Subject: Re: Gnulib's freopen replacement and MinGW
Date: Mon, 07 May 2012 06:44:00 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 05/05/2012 05:18 AM, Eli Zaretskii wrote:
> Diffutils 3.2 call xfreopen with its first argument NULL, expecting
> the underlying reopen to handle this.  However, the MS runtime does
> not implement the Posix semantics of such a call,

POSIX says that such a call is implementation-defined, so technically,
mingw DOES implement the POSIX semantics (by defining that it is
unsupported).  However, you are correct that it is annoying, and
something that gnulib could work around for easier coding.

> The following change fixes this:
> 
> 2012-05-05  Eli Zaretskii  <address@hidden>
> 
>       * lib/freopen.c [_WIN32]: Include io.h and fcntl.h.
>       (rpl_freopen) [_WIN32]: If the first argument is NULL, call
>       _setmode to switch STREAM to either binary or text mode, as
>       specified by MODE.
> 
> --- lib/freopen.c~0   2011-09-02 01:35:11.000000000 +0300
> +++ lib/freopen.c     2012-05-05 13:46:36.389000000 +0300
> @@ -37,11 +37,23 @@ orig_freopen (const char *filename, cons
>  
>  #include <string.h>
>  
> +#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> +#include <io.h>
> +#include <fcntl.h>
> +#endif
> +
>  FILE *
>  rpl_freopen (const char *filename, const char *mode, FILE *stream)
>  {
>  #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> -  if (filename != NULL && strcmp (filename, "/dev/null") == 0)
> +  if (filename == NULL)
> +    {
> +      if (strchr (mode, 'b'))
> +     return _setmode (_fileno (stream), _O_BINARY) == -1 ? NULL : stream;
> +      else
> +     return _setmode (_fileno (stream), _O_TEXT) == -1 ? NULL : stream;

Shouldn't we be doing some sanity checking, as in ensuring that a
read-only stream is not being reopened with 'w', or a write-only stream
is not being reopened with 'r'?  Also, shouldn't we be honoring 'w' vs.
'a' and adjusting the underlying fd's O_APPEND bit accordingly?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]