simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  7b79d220 Work around console I/O size limit on Windows 7.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2020-01-26 10:31:18

commit 7b79d22021296e4ae941b383ab34971a9f2b0a1b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7b79d22021296e4ae941b383ab34971a9f2b0a1b;hp=7bcbc79818a8db820d90ca5b2c040618030cc7dd
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Jan 26 09:50:07 2020 +0000

    Work around console I/O size limit on Windows 7.
    
    A user reports that the ReadFile call in console_get_userpass_input
    fails with ERROR_NOT_ENOUGH_MEMORY on Windows 7, and further reports
    that this problem only happens if you tell ReadFile to read more than
    31366 bytes in a single call.
    
    That seems to be a thing that other people have found as well: I
    turned up a similar workaround in Ruby's Win32 support module, except
    that there it's for WriteConsole. So I'm reducing my arbitrary read
    size of 64K to 16K, which is well under that limit.
    
    This issue became noticeable in PuTTY as of the recent commit
    cd6bc14f0, which reworked console_get_userpass_input to use strbufs.
    Previously we were trying to read an amount proportional to the
    existing size of the buffer, so as to grow the buffer exponentially to
    save quadratic-time reallocation. That was OK in practice, since the
    initial read size was nice and small. But in principle, the same bug
    was present in that version of the code, just latent - if we'd ever
    been called on to read a _really large_ amount of data, then
    _eventually_ the input size parameter to ReadFile would have grown
    beyond that mysterious limit!

 windows/wincons.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)