bug#6149: 24.0.50; shell buffer overflow when input longer than 4096 bytes

[Charles A. Roelli]

> From: jidanni@jidanni.org
> Date: Mon, 10 May 2010 12:14:54 +0800
> 
> This is a serious bug in M-x shell. It is not a bash or dash bug. It is
> not a readline bug. It does not happen in xterm. It does not happen when
> using pipes or backticks to get the input. It only happens in M-x
> shell... when one gives lines longer than ~4096 characters.
> 
> Actually it is not buffer overflow, but buffer truncation, with NO
> WARNING to the user. One day the wrong file will get removed via this
> mess.
> 
> In GNU Emacs 24.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
>  of 2010-05-01 on elegiac, modified by Debian
>  (emacs-snapshot package, version 1:20100501-1)
> 
> 
> [application/octet-stream input_truncation.txt.gz (2kB)]

I can still reproduce this bug in 26.1 with the following recipe:

M-x shell RET
echo SPC C-SPC
C-u 5000 a RET
C-p C-e
M-=

On GNU/Linux: Region has 2 lines, 2 words, and 9096 characters.

If echo had received all of the input, you would expect around 10000
characters in the region.  Instead, there are 5000 + 4096 characters.

Back when EOF chars were used to flush output, we had an "fpathconf"
check as in:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3d082a269ece18058ed82957f8a056822b39789e

It might be possible to reinstate this "fpathconf" check to warn the
user that he has gone over the PTY limit, or maybe to prevent overlong
lines from being sent at all.

There is further discussion at:

http://lists.gnu.org/archive/html/emacs-devel/2010-08/msg00209.html


(Also, repeating this recipe on macOS with Emacs 26.1 results in the
behavior pointed out in Bug#32438.)