X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 5D873384D1B3
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=cs.umass.edu
Authentication-Results:	sourceware.org; spf=pass smtp.mailfrom=cs.umass.edu
Subject:	Re: Bug in Control-d handling?
To:	Ken Brown <kbrown AT cornell DOT edu>, cygwin AT cygwin DOT com
References:	<827e2006-2aae-9f7f-9c3f-eef3a7c6e793 AT cornell DOT edu>
	<20220620175935 DOT 924a49feb13156f1a3cf3da4 AT nifty DOT ne DOT jp>
	<20220620192223 DOT 2e0a084a7c093939b1c7c8d6 AT nifty DOT ne DOT jp>
	<5c548a4c-b7ea-b7e0-6ab6-ea0e94ce66a1 AT cornell DOT edu>
From:	Eliot Moss <moss AT cs DOT umass DOT edu>
Message-ID:	<0ce1465e-b9fd-8794-8707-ee4b2ff4cbb4@cs.umass.edu>
Date:	Mon, 20 Jun 2022 09:53:15 -0400
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
	Thunderbird/68.12.1
MIME-Version:	1.0
In-Reply-To:	<5c548a4c-b7ea-b7e0-6ab6-ea0e94ce66a1@cornell.edu>
X-Spam-Status:	No, score=-8.0 required=5.0 tests=BAYES_00, GIT_PATCH_0,
	JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS,
	TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	moss AT cs DOT umass DOT edu
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On 6/20/2022 9:24 AM, Ken Brown wrote:
 > On 6/20/2022 6:22 AM, Takashi Yano wrote:
 >> On Mon, 20 Jun 2022 17:59:35 +0900
 >> Takashi Yano wrote:
 >>> Isn't this a bug of newlib? Try following code.
 >>>
 >>> #include <stdio.h>
 >>>
 >>> int main()
 >>> {
 >>>     printf("%d\n", getchar());
 >>>     printf("%d\n", feof(stdin));
 >>>     printf("%d\n", getchar());
 >>>     return 0;
 >>> }
 >>>
 >>> If you press Ctrl-D at the first getchar(), the second getchar()
 >>> does not return EOF while it does in linux.
 >>>
 >>> The following patch seems to resolve the issue.
 >>>
 >>> diff --git a/newlib/libc/stdio/refill.c b/newlib/libc/stdio/refill.c
 >>> index ccedc7af7..843163b7e 100644
 >>> --- a/newlib/libc/stdio/refill.c
 >>> +++ b/newlib/libc/stdio/refill.c
 >>> @@ -47,11 +47,9 @@ __srefill_r (struct _reent * ptr,
 >>>     fp->_r = 0;            /* largely a convenience for callers */
 >>> -#ifndef __CYGWIN__
 >>>     /* SysV does not make this test; take it out for compatibility */
 >>>     if (fp->_flags & __SEOF)
 >>>       return EOF;
 >>> -#endif
 >>>     /* if not already reading, have to be reading and writing */
 >>>     if ((fp->_flags & __SRD) == 0)
 >>>
 >>> However, I am not sure what this #ifndef __CYGWIN__ is for.
 >>
 >> Ah, I confirmed that System V (Solaris 11.4) behaves like that.
 >> Does cygwin aim for System V compatibility???
 >
 > Thanks for tracking this down!
 >
 > I don't recall any situation in which Cygwin preferred System V compatibility over Linux
 > compatibility.  I'm attaching the commit (from November 2004) in which the #ifndef __CYGWIN__ was
 > introduced.  There's no indication in the commit message as to the reason for the change.  I also
 > didn't see anything relevant in the cygwin or cygwin-developers mailing lists from November 2004,
 > but I might have missed it.
 >
 > I think that commit should probably be reverted, but we should wait until Corinna is available.
 > Even though the issue is in newlib code, the code only affects Cygwin, so there's probably no need
 > to involve the newlib list.  But again, that's Corinna's call.

Good idea to wait for Corinna.  I did a smidge of research, looking through
the Wikipedia page on the POSIX terminal interface.  It suggests that this
part was largely borrowed from System-V, so that may explain what we see in
newlib.  And looking up the POSIX spec, it says this:

"Special character on input, which is recognized if the ICANON flag is
set. When received, all the bytes waiting to be read are immediately passed to
the process without waiting for a <newline>, and the EOF is discarded. Thus,
if there are no bytes waiting (that is, the EOF occurred at the beginning of a
line), a byte count of zero shall be returned from the read(), representing an
end-of-file indication. If ICANON is set, the EOF character shall be discarded
when processed."

This suggests that indeed control-D will need to be typed twice before a
blocking read on a terminal with ICANON will appear to be at eof.  I guess we
can consider getchar to be (almost) like a read of size 1, except where read
would return 0, getchar returns -1.

The quoted text above implies that the second control-D will set the
end-of-file indicator.  So I agree that it looks like the ifndef should be
removed.  And of course, wherever we said control-D, EOF should be implied (it
is normally control-D, but the user can change which character is associated
with the EOF semantics).

Cheers - Eliot

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

- Raw text -