simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  1bcf2a83 Remove spurious 'return' in void method wrappers.
  ce780c9b Add casts to silence VS warnings in GET_32BIT et al.
  dfc215d0 Remove ASCII fallback in format_numeric_keypad_key().

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-04-06 10:59:01

commit 1bcf2a8397849c770872f6e593cea0583ea43f66
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1bcf2a8397849c770872f6e593cea0583ea43f66;hp=77bdaa2436fa1f7fefb529b7354e8b35944a5f50
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 6 10:12:31 2019 +0100

    Remove spurious 'return' in void method wrappers.
    
    For some reason, only Visual Studio bothers to give a warning when you
    write "return g()" inside a function f() when both f and g have void
    return type.
    
    (Of course it would be cleaner and more orthogonal if that was simply
    legal C in the first place - but given that it's not, it would be nice
    if more compilers let me know about it so I could fix it...)

 network.h | 8 ++++----
 ssh.h     | 8 ++++----
 sshchan.h | 4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

commit ce780c9b33b9896e90e97fa73436fa60eeea4f18
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ce780c9b33b9896e90e97fa73436fa60eeea4f18;hp=1bcf2a8397849c770872f6e593cea0583ea43f66
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 6 10:25:27 2019 +0100

    Add casts to silence VS warnings in GET_32BIT et al.
    
    Visual Studio is quite aggressive about displaying warnings everywhere
    that you implicitly narrow from one integer type to another, and I've
    not generally felt it improves readability to add enough explicit casts
    to silence the warnings. But the ones in the inline functions in misc.h
    are literally two orders of magnitude more annoying than the rest,
    because that file gets included in nearly every translation unit, so the
    warnings come up over 100 times each. So I think these are worth fixing.

 misc.h | 56 ++++++++++++++++++++++++++++----------------------------
 1 file changed, 28 insertions(+), 28 deletions(-)

commit dfc215d0c07ebfc990304a3f6544420eb717e8ef
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dfc215d0c07ebfc990304a3f6544420eb717e8ef;hp=ce780c9b33b9896e90e97fa73436fa60eeea4f18
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 6 10:45:40 2019 +0100

    Remove ASCII fallback in format_numeric_keypad_key().
    
    TranslateKey() on Windows passed all numeric-keypad key events to this
    function in terminal.c, and accepted whatever it gave back. That
    included the handling for the trivial case of the numeric keypad, when
    Num Lock is on and application keypad mode hasn't overridden it, so
    that the keypad should be returning actual digits. In that case,
    format_numeric_keypad_key() itself was returning the same ASCII
    character I had passed in to it as a keypad identifier, and
    TranslateKey was returning that in turn as the final translation.
    
    Unfortunately, that means that with Num Lock on, the numeric keypad
    translates into what _I_ used as the logical keypad codes inside the
    source code, not what the local keyboard layout thinks are the right
    codes. In particular, the key I identified as keypad '.' would render
    as '.' even on a German keyboard where it ought to produce ','.
    
    Fixed by removing the fallback case in format_numeric_keypad_key()
    itself, so now it returns the empty string if it didn't produce an
    escape sequence as its translation. Instead, the special case is in
    window.c, which checks for a zero-length output string and handles it
    by falling through to the keyboard-layout specific ToUnicode code
    further down TranslateKey().
    
    On the GTK side, no change is needed here: the GTK keyboard handler
    does things in the opposite order, by trying the local input method
    _first_ (unless it can see a reason up front to override it), and only
    calling format_numeric_keypad_key() if that didn't provide a
    translation. So the fallback ASCII translation in the latter was
    already not used.

 terminal.c       |  6 ------
 windows/window.c | 24 ++++++++++++++++++++----
 2 files changed, 20 insertions(+), 10 deletions(-)