/dev/null regression in Cygwin 3.6.1

[Bruno Haible]

Here's a smaller reproducer.

============================ foo.c ============================
#include <stdio.h>
#include <windows.h>
#include <io.h>

int main ()
{
  HANDLE h = (HANDLE) _get_osfhandle (0);
  fprintf (stderr, "h = 0x%08x\n", h);
  fprintf (stderr, "FileType is CHAR ? %d\n", GetFileType (h) == FILE_TYPE_CHAR);
  int ret = WaitForSingleObject (h, 0);
  if (ret == WAIT_OBJECT_0)
    fprintf (stderr, "WaitForSingleObject -> WAIT_OBJECT_0\n");
  else if (ret == WAIT_TIMEOUT)
    fprintf (stderr, "WaitForSingleObject -> WAIT_TIMEOUT\n");
  else if (ret == WAIT_ABANDONED)
    fprintf (stderr, "WaitForSingleObject -> WAIT_ABANDONED\n");
  else if (ret == WAIT_FAILED)
    fprintf (stderr, "WaitForSingleObject -> WAIT_FAILED\n");
}
===============================================================
Compile this file as a native Windows program (mingw for example).
Then, in a Cygwin shell window, do
$ ./a < /dev/null

Result in 3.4.6:

h = 0x000001e8
FileType is CHAR ? 1
WaitForSingleObject -> WAIT_OBJECT_0

Result in 3.6.1:

h = 0x00000358
FileType is CHAR ? 1
WaitForSingleObject -> WAIT_TIMEOUT

> Looking through the commits between 3.6.0 and 3.6.1, the most likely culprit
> is commit d750786e7de013b58e2968eeb6a7fd59dcc535c9 .

Especially since this commit modified select.cc, removing a comment
  /* TODO: Buffer really full or non-Cygwin reader? */
and here we are exactly in that case: a non-Cygwin process reading from
Cygwin's /dev/null.

Takashi Yano, can you please look at it and restore the previous behaviour?

Bruno