From: Paul Eggert <eggert@cs.ucla.edu>
To: Spencer Baugh <sbaugh@janestreet.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 6149@debbugs.gnu.org, Dmitry Gutov <dmitry@gutov.dev>,
monnier@iro.umontreal.ca, jidanni@jidanni.org
Subject: bug#6149: bug#24531: process-send-string seems to truncate lines over 4096 characters
Date: Thu, 27 Jul 2023 07:51:31 -0700 [thread overview]
Message-ID: <c22231e8-fe01-addf-9a1a-43b7e46200c0@cs.ucla.edu> (raw)
In-Reply-To: <iery1j1sbdy.fsf_-_@janestreet.com>
On 2023-07-27 06:59, Spencer Baugh wrote:
>> AFAIU, that is based on the errno value returned by a 'write' call
>> which attempts to write too many bytes (see the would_block function).
>> I guess writes to PTYs don't do that?
> Writes to PTYs do tell us when the data has been truncated.
Unfortunately not. Data bytes are silently truncated, at least on Ubuntu
23.04. If I fire up Emacs and type:
M-x shell RET cat >out RET C-u 4096 x RET C-d
the last RET causes Emacs to write 4097 bytes (4096 'x's followed by a
newline) to the pty. This 'write' system call succeeds and returns 4097.
However, the two 'read' calls that 'cat' executes see only 4095 'x's
followed by '\n' ('read' returns 4096) followed by EOF ('read' returns
0). An 'x' was lost, and Emacs has no way to see this directly.
This comes from the canonical mode of Linux's terminal driver, which
silently discards non-newline bytes after the 4095th byte of an input
line. See:
https://github.com/torvalds/linux/blob/v6.4/drivers/tty/n_tty.c#L1648
One possibility is that Emacs could monitor writes to a Linux pty,
looking for too many non-newline bytes in a row, and warn the user if
that number exceeds 4095. That might be the best it can do in this
troublesome environment. (The warning would be irrelevant for ttys
operating in non-canonical mode, which have a different set of problems.)
next prev parent reply other threads:[~2023-07-27 14:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 4:14 bug#6149: 24.0.50; shell buffer overflow when input longer than 4096 bytes jidanni
2010-06-01 1:50 ` Stefan Monnier
2023-07-20 20:15 ` bug#6149: bug#24531: process-send-string seems to truncate lines over 4096 characters Spencer Baugh
2023-07-20 21:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-21 5:39 ` Eli Zaretskii
2023-07-21 13:58 ` Spencer Baugh
2023-07-21 14:18 ` Eli Zaretskii
2023-07-27 1:48 ` bug#6149: " Dmitry Gutov
2023-07-27 5:41 ` Eli Zaretskii
2023-07-27 13:59 ` Spencer Baugh
2023-07-27 14:51 ` Paul Eggert [this message]
2023-07-21 15:09 ` bug#24531: " Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2018-09-28 20:13 ` bug#6149: 24.0.50; shell buffer overflow when input longer than 4096 bytes Charles A. Roelli
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/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c22231e8-fe01-addf-9a1a-43b7e46200c0@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=6149@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=jidanni@jidanni.org \
--cc=monnier@iro.umontreal.ca \
--cc=sbaugh@janestreet.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).