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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
