simon-git: putty (pre-0.83): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  19798515 ldisc_send: return early if len == 0.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: pre-0.83
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2025-01-16 07:35:53

commit 19798515df5db3151370e331ca1312bb39fadf16
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=19798515df5db3151370e331ca1312bb39fadf16;hp=e7acb9f6968d48217a4210dd91b742e82f80bc72
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jan 16 07:24:06 2025 +0000

    ldisc_send: return early if len == 0.
    
    This can come up, for example, if the terminal receives a ^E character
    and has an empty answerback string configured.
    
    Without this early return, we append zero bytes to ldisc's ordinary
    bufchain input_queue, which is harmless; but we also append a
    zero-length record to ldisc's list of (type, length) chunks describing
    which parts of the input bufchain should be treated as interactive or
    as coming from special dedicated keystrokes (e.g. telling Return apart
    from ^M).
    
    That zero-length record is not _immediately_ harmful, but when the
    user next presses a key, it will have a different type from the empty
    answerback data, so that another chunk record is appended to the list
    after the zero-length one. And then ldisc_input_queue_callback goes
    into a tight loop, because it keeps trying to consume bytes from the
    start of the input bufchain but bounding the size at the length of the
    first (type, length) chunk, which is zero. So it consumes 0 bytes,
    finds the bufchain still isn't empty, and loops round again.

 ldisc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)