From: Mark H Weaver <mhw@netris.org>
To: Neil Jerram <neil@ossau.homelinux.net>
Cc: geiser-users@nongnu.org, 33403@debbugs.gnu.org
Subject: bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation
Date: Fri, 16 Nov 2018 02:13:40 -0500 [thread overview]
Message-ID: <87y39t1olc.fsf@netris.org> (raw)
In-Reply-To: <87d0r5349t.fsf@netris.org> (Mark H. Weaver's message of "Fri, 16 Nov 2018 01:49:39 -0500")
Mark H Weaver <mhw@netris.org> writes:
> If, after pasting this, you type another close quote, 5 close parens,
> and then repaste the last two lines, it will print the garbled input and
> return to a prompt.
Actually, instead of pasting the last two lines as-is, I replaced
"(length classification)" with "classification", so that instead of
printing the length, it prints the actual s-exp. Then you can see what
happened to that final string literal.
> Anyway, to make a long story short, after some debugging, I found that
> precisely the same truncation of the first line happens when using 'cat'
> from GNU coreutils. Simply type 'cat' and paste the same text, and
> you'll see that in the output, only the first 4095 bytes of the first
> line were retained.
>
> So, I'm not sure where the problem is, but it's not a problem in Guile.
This is a documented limitation in Linux's terminal handling when in
canonical mode. See the termios(3) man page, which includes this text:
Canonical and noncanonical mode
The setting of the ICANON canon flag in c_lflag determines
whether the terminal is operating in canonical mode (ICANON set)
or noncanonical mode (ICANON unset). By default, ICANON is set.
In canonical mode:
* Input is made available line by line. An input line is
available when one of the line delimiters is typed (NL, EOL,
EOL2; or EOF at the start of line). Except in the case of EOF,
the line delimiter is included in the buffer returned by
read(2).
* Line editing is enabled (ERASE, KILL; and if the IEXTEN flag is
set: WERASE, REPRINT, LNEXT). A read(2) returns at most one
line of input; if the read(2) requested fewer bytes than are
available in the current line of input, then only as many bytes
as requested are read, and the remaining characters will be
available for a future read(2).
* The maximum line length is 4096 chars (including the
terminating newline character); lines longer than 4096 chars
are truncated. After 4095 characters, input processing (e.g.,
ISIG and ECHO* processing) continues, but any input data after
4095 characters up to (but not including) any terminating
newline is discarded. This ensures that the terminal can
always receive more input until at least one line can be read.
Note that last item above.
Mark
next prev parent reply other threads:[~2018-11-16 7:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87sh021kw2.fsf@ossau.homelinux.net>
[not found] ` <878t1ugyf9.fsf@nicolasgoaziou.fr>
[not found] ` <87h8gi1g5g.fsf@ossau.homelinux.net>
[not found] ` <871s7mz357.fsf@imladris>
[not found] ` <87bm6q1c33.fsf@ossau.homelinux.net>
[not found] ` <87bm6q1c33.fsf-mq78CtbEgnGjF4gvJNWmbtHuzzzSOjJt@public.gmane.org>
2018-11-15 22:33 ` Data length limit in Guile/Geiser/Scheme evaluation Neil Jerram
2018-11-16 6:49 ` bug#33403: [Geiser-users] " Mark H Weaver
2018-11-16 7:13 ` Mark H Weaver [this message]
2018-11-16 10:44 ` Neil Jerram
2018-11-16 11:16 ` Neil Jerram
2018-11-16 22:40 ` bug#33403: [Geiser-users] bug#33403: " Jose A. Ortega Ruiz
[not found] ` <875zwx1dcn.fsf@ossau.homelinux.net>
2018-11-16 23:12 ` Jose A. Ortega Ruiz
[not found] ` <87va4wwra7.fsf@imladris>
2018-11-17 7:09 ` Mark H Weaver
[not found] ` <87zhu8w55u.fsf@netris.org>
2018-11-17 7:31 ` Mark H Weaver
2018-11-17 14:59 ` Jose A. Ortega Ruiz
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y39t1olc.fsf@netris.org \
--to=mhw@netris.org \
--cc=33403@debbugs.gnu.org \
--cc=geiser-users@nongnu.org \
--cc=neil@ossau.homelinux.net \
/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).