simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  6f4083e6 Fix double display glitch in erase_lots().
  50853ddc winnet.c: improve 64-bit-cleanness in cmpfortree.

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:           2019-08-11 14:09:14

commit 6f4083e682a072317da55d6f6c1851f12b5f1119
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=6f4083e682a072317da55d6f6c1851f12b5f1119;hp=efcf164abe29eaf3357a63219830af4a71058af4
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Aug 8 18:05:16 2019 +0100

    Fix double display glitch in erase_lots().
    
    If the cursor is on the rightmost column of the terminal and
    term->wrapnext is set, and the user asks to erase from the current
    position to the end of (at least) the line, what should happen?
    
    PuTTY's previous behaviour was to ignore term->wrapnext, and do the
    same thing we would have done without it: erase from the current
    physical cursor position to EOL inclusive, i.e. blank the character
    cell we just printed.
    
    But this is unfortunate if a program writes an interleaving of
    printing characters and ESC[K, which I recently found out is what gcc
    does in its colour-highlighted error messages: if the last printed
    char just before an ESC[K pushes the cursor into the deferred-wrap
    state, then the ESC[K blanks that character, and then we wrap to the
    next line. So one character of the error message ends up missing.
    
    xfce4-terminal and gnome-terminal take the approach in this situation
    of regarding the cursor position as _right_ at the end of the line, so
    no character cells get cleared at all, and the error message displays
    as intended. I think that's more sensible, so I've switched to doing
    the same thing.
    
    (xterm has different behaviour again: it blanks the character cell and
    also clears its analogue of the wrapnext flag. So in _their_ handling
    of this sequence of output, one character of the error message is
    still missing, but it looks as if it's been _omitted_ rather than
    replaced by a space.)
    
    Secondly, in the course of fixing that, I looked at the check_boundary
    call in erase_lots, which is supposed to ensure that if a wide CJK
    character straddles the boundary between what's being erased and what
    isn't, then both halves of the character are deleted. I had to modify
    that anyway because I was moving that very boundary, and in doing so,
    I noticed that even according to the previous behaviour, it had an
    off-by-one error. In the case where you send ESC[1K (meaning erase up
    to and including the cursor position), the call to check_boundary was
    performed on the _left_ edge of the cursor's character cell, when it
    should have been the right edge. So you could end up with an
    erase_char in the left half (i.e. a space) and still have the magic
    value UCSWIDE in the right half, causing the terminal to think you had
    a double-width U+0020 on the screen, which isn't supposed to be able
    to happen.

 terminal.c | 41 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 37 insertions(+), 4 deletions(-)

commit 50853ddcc3f78cf28b84704abcd686ab865d4089
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=50853ddcc3f78cf28b84704abcd686ab865d4089;hp=6f4083e682a072317da55d6f6c1851f12b5f1119
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Aug 9 19:24:20 2019 +0100

    winnet.c: improve 64-bit-cleanness in cmpfortree.
    
    Commit f2e61275f converted the integer casts in cmpforsearch to
    uintptr_t from unsigned long. But it left the companion function
    cmpfortree alone, presumably on the grounds that the compiler didn't
    report a warning for that one.
    
    But those two functions (cmpfortree and cmpforsearch) are used with
    the same tree234, so they're supposed to implement the same sorting
    criterion. And the thing they're actually comparing, namely the
    Windows API typedef SOCKET, is a pointer-sized integer. So there was a
    latent bug here in which cmpforsearch was comparing all 64 bits of the
    pointer, while cmpfortree was only comparing the low-order 32.

 windows/winnet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)