In 2021 (and exacerbated several times over the last couple years since then), cygwin added some code to sets a flag that is not well supported by the NT kernel and documented as being something that should not be set (PIPE_NOWAIT at https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-setnamedpipehandlestate). It was originally added in cygwin/cygwin@d0ad52a, but now changed to be guaranteed to expose this undefined behavior to other applications in https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fc691d0246b95807cd2fac83cceb8053fc295eb2. I am not entirely sure this is something that libuv should fix, as this is clearly a cygwin bug with setting a flag that the kernel documentation says should never be set. However, it is possible that libuv should try to be robust against this, as we might start seeing bug reports now where using libuv+cygwin will now result in corrupted IO.
In 2021 (and exacerbated several times over the last couple years since then), cygwin added some code to sets a flag that is not well supported by the NT kernel and documented as being something that should not be set (PIPE_NOWAIT at https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-setnamedpipehandlestate). It was originally added in cygwin/cygwin@d0ad52a, but now changed to be guaranteed to expose this undefined behavior to other applications in https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fc691d0246b95807cd2fac83cceb8053fc295eb2. I am not entirely sure this is something that libuv should fix, as this is clearly a cygwin bug with setting a flag that the kernel documentation says should never be set. However, it is possible that libuv should try to be robust against this, as we might start seeing bug reports now where using libuv+cygwin will now result in corrupted IO.