simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  efdbe56 A few more missing frees.
  54720b2 Remove a redundant ?: in the nethack_keypad code.
  1266ac0 uxpgnt: correct control flow in find_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:           2017-02-15 05:53:57

commit efdbe568e2d0ab58aa0330fda392c4c12f92dc1c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=efdbe568e2d0ab58aa0330fda392c4c12f92dc1c;hp=991d30412d0911e7727a852d0a00ae0f1bec1b3e
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Feb 15 05:31:51 2017 +0000

    A few more missing frees.
    
    Naturally I didn't quite manage to catch _everything_ Coverity
    reported to me in my first pass through the results.

 pageant.c | 4 ++++
 1 file changed, 4 insertions(+)

commit 54720b2c5a36648864d7bfc6547ef86168db1865
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=54720b2c5a36648864d7bfc6547ef86168db1865;hp=efdbe568e2d0ab58aa0330fda392c4c12f92dc1c
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Feb 15 05:21:13 2017 +0000

    Remove a redundant ?: in the nethack_keypad code.
    
    I think all of the cases in this switch must have originally said
    (shift_state ? 'this' : 'that'), and in all but the VK_NUMPAD5 case
    the two options were different, and I left VK_NUMPAD5 containing a
    redundant ?: just to make it line up in a nice table with the others.
    But now the others all have more options than that because I had to
    support Ctrl as well as Shift modifiers, so there's no reason to have
    that silly ?: lingering around (and it annoys Coverity).

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

commit 1266ac0e304b4e4db809eb045b8ac5dc43f299c4
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1266ac0e304b4e4db809eb045b8ac5dc43f299c4;hp=54720b2c5a36648864d7bfc6547ef86168db1865
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Feb 15 05:31:30 2017 +0000

    uxpgnt: correct control flow in find_key().
    
    If we try to interpret a string argument as the name of a key file,
    sometimes we it's in circumstances where we _know_ it's a key file, so
    we must print an error message and return failure if the file can't be
    loaded. Other times it's not, and we just fall back to interpreting
    the argument in some other way (e.g. as a pattern match against the
    comment or fingerprint of a key already in the agent).
    
    My code dealing with failure returns from the public-key loading
    functions were mishandling the latter case, if they identified a file
    as existing and looking more or less like some kind of key file but
    then it turned out to have a format error; they would try to copy and
    return a public key that they didn't actually have. Even if
    pageant_pubkey_copy avoided crashing as a result, this would still
    inhibit the fallback to treating the input string as some other kind
    of pattern match.

 unix/uxpgnt.c | 48 ++++++++++++++++++++++++------------------------
 1 file changed, 24 insertions(+), 24 deletions(-)