unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
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





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