[Mingw-users] Known? fdopen(0,"rb") fails to achieve binary mode

[Soren A. <sor...@sp...>]

Hello,

Is it a known issue that using the gcc-win32 ports (MinGW for sure,
Cygwin maybe), the ANSI C library call fdopen() is buggy or weird?

Testcase: try the arguments to fdopen thusly:
   fdopen ( fileno(stdin), "rb" );
as would happen if one was trying to handle redirection (anon pipe or
<). This stdin redirected from another program's stdout will NOT be in
binary mode, it will be in text mode, and the calling program will
likely error if it is requiring a binary read.

I've seen programmers do some of this:
#ifdef WIN32
#  define USE_SETMODE 1
#endif
.
.
.
#ifdef USE_SETMODE
   setmode( fileno(stdin), O_BINARY );
#endif

In order to compensate for this. Is this special case really a bug, or
is it a technicality, something like "because the stdout is already
open, we aren't technically opening a new file descriptor, but rather
just referring to an existing one, so we don't call this a bug [maybe
we call it 'one of the many extraordinary pleasures of working on
windoze']"?

Given how common the operation described is, I find it a little
startling that I had to spend several hours figuring this out last
weekend. So I am mentioning it here in hopes it might be findable
(search engines) and thereby save somebody else some head-scratching
(the Cygwin documentation does mention the use of setmode but doesn't
at all point out the special trouble you're in if you try to treat
stdin as if it was just like any other file, using fdopen()).

    Regards,
      Soren Andersen