On Mon, 14 Apr 2025 15:03:16 +0200
Bruno Haible wrote:
> 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?
Thanks for the new testcase. I think the issue has been fixed in:
cygwin-3.7.0-0.68.g37c49decc835 (Test)
Please test.
--
Takashi Yano <takashi.y...@nifty.ne.jp>
--
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
