DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 53EFOpKu1058511
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9393C3858C54
Date: Mon, 14 Apr 2025 08:23:45 -0700 (PDT)
To: Bruno Haible <bruno@clisp.org>
Subject: Re: /dev/null regression in Cygwin 3.6.1
In-Reply-To: <19390375.kOAnuia59f@nimes>
Message-ID: <19559959-a4f5-2d6f-369b-8da6f1f9efca@jdrake.com>
References: <10514352.ICPdZLu4VQ@nimes> <19390375.kOAnuia59f@nimes>
MIME-Version: 1.0
Precedence: list
From: Jeremy Drake via Cygwin <cygwin@cygwin.com>
Reply-To: Jeremy Drake <cygwin@jdrake.com>
Cc: cygwin@cygwin.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Mon, 14 Apr 2025, Bruno Haible via Cygwin wrote:

> 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.

That's Cygwin's select, it shouldn't have any bearing on what a non-Cygwin
process sees.

What I'm not getting is why ./something < /dev/null should be any
different than doing in CMD something < NUL - I would hope there's not a
pipe to Cygwin to deal with /dev/null but rather just a handle to
Windows' NUL device...

-- 
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