From: Ken Brown <kbrown@cornell.edu>
To: moss@cs.umass.edu, cygwin@cygwin.com
Subject: Re: Bug in Control-d handling?
Date: Mon, 20 Jun 2022 13:50:23 -0400 [thread overview]
Message-ID: <7a999f10-eda4-c9e5-725a-2d3e3524eef8@cornell.edu> (raw)
In-Reply-To: <0ce1465e-b9fd-8794-8707-ee4b2ff4cbb4@cs.umass.edu>
On 6/20/2022 9:53 AM, Eliot Moss wrote:
> 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).
I would frame the issue slightly differently, since this is not just about
terminals; the code we're discussing applies to any file. Suppose EOF has been
seen in a call to one of the stdio input functions. Prior to commit 1f8f7e2d,
any further calls to those functions would immediately return EOF. Since that
commit, however, another attempt is made to read, and the EOF indicator for the
file is turned off if input is found. In many cases (e.g., an ordinary disk
file), this second read will still return EOF. In other cases (e.g., a
terminal), the second read might block if there's still no input available.
Ken
next prev parent reply other threads:[~2022-06-20 17:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-19 19:08 Ken Brown
2022-06-20 8:59 ` Takashi Yano
2022-06-20 10:22 ` Takashi Yano
2022-06-20 13:24 ` Ken Brown
2022-06-20 13:53 ` Eliot Moss
2022-06-20 17:50 ` Ken Brown [this message]
2022-07-04 8:10 ` Corinna Vinschen
2022-06-20 17:12 ` Achim Gratz
2022-06-20 19:22 ` Brian Inglis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7a999f10-eda4-c9e5-725a-2d3e3524eef8@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
--cc=moss@cs.umass.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).