simon-git: putty (master): Simon Tatham

Sun Jan 13 10:10:52 GMT 2019

TL;DR:
  5afefef7 testcrypt: remove underscores from value-type names.
  47ca2e98 testcrypt.py: look past 'opt_' prefix on argument types.
  d4d89d51 Move some of winmisc.c into winmiscs.c.
  2a365bb0 testcrypt: fix a technically illegal forward-typedef.
  fdc48006 Build testcrypt on Windows.
  80f2f6e7 Fix mp_mul_add_simple on Visual Studio.

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-01-13 10:10:52

commit 5afefef798b5007ad65696c1900e204e03b6a701
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5afefef798b5007ad65696c1900e204e03b6a701;hp=b7be22e4e03374d4a01e4dfb5dd776294bacb1cf
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Jan 9 21:59:19 2019 +0000

    testcrypt: remove underscores from value-type names.

    The type names 'val_foo' used in testcrypt.h work on a system where a
    further underscore suffix is treated as a qualifier indicating
    something about how the C version of the API represents that type.
    (For example, plain 'val_string' means a strbuf, but if I write
    'val_string_asciz' or 'val_string_ptrlen' in testcrypt.h it will cause
    the wrapper for that function to pass a char * or a ptrlen derived
    from that strbuf.)

    But I forgot about this when I named the type val_ssh2_cipher (and
    ditto ssh1), with the effect that the testcrypt system has considered
    them all along to really be called 'ssh2' and 'ssh1', and the 'cipher'
    to be some irrelevant API-adaptor suffix.

    This hasn't caused a bug because I didn't have any other type called
    val_ssh2_something. But it was a latent one. Now renamed sensibly!

 testcrypt.c |  6 +++---
 testcrypt.h | 24 ++++++++++++------------
 2 files changed, 15 insertions(+), 15 deletions(-)

commit 47ca2e98a51848142ef7d4994b45e92363006646
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=47ca2e98a51848142ef7d4994b45e92363006646;hp=5afefef798b5007ad65696c1900e204e03b6a701
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jan 10 19:21:33 2019 +0000

    testcrypt.py: look past 'opt_' prefix on argument types.

    When testcrypt.h lists a function argument as 'opt_val_foo', it means
    that the argument is optional in the sense that the C function can
    take a null pointer in place of a valid foo, and so the Python wrapper
    module should accept None in the corresponding argument slot from the
    client code and translate it into the special string "NULL" in the
    wire protocol.

    This works fine at argument translation time, but the code that reads
    testcrypt.h wasn't looking at it, so if you said 'opt_val_foo_suffix'
    in place of 'opt_val_foo' (indicating that that argument is optional
    _and_ the C function expects it in a translated form), then the
    initial pass over testcrypt.h wouldn't strip the _suffix, and would
    set up data structures with mismatched type names.

 test/testcrypt.py | 4 ++++
 1 file changed, 4 insertions(+)

commit d4d89d51e95532735e629f3a72aeb34b09100d39
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d4d89d51e95532735e629f3a72aeb34b09100d39;hp=47ca2e98a51848142ef7d4994b45e92363006646
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 11 06:39:52 2019 +0000

    Move some of winmisc.c into winmiscs.c.

    That's a terrible name, but winutils.c was already taken. The new
    source file is intended to be to winmisc.c as the new utils.c is to
    misc.c: it contains all the parts that are basically safe to link into
    _any_ Windows program (even standalone test things), without tying in
    to the runtime infrastructure of the main tools, referring to any
    other PuTTY source module, or introducing an extra Win32 API library
    dependency.

 Recipe             |   7 +-
 windows/winmisc.c  | 258 ---------------------------------------------------
 windows/winmiscs.c | 265 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 269 insertions(+), 261 deletions(-)

commit 2a365bb08ac308b7068b99d80938ec4c5a027593
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=2a365bb08ac308b7068b99d80938ec4c5a027593;hp=d4d89d51e95532735e629f3a72aeb34b09100d39
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 11 19:13:27 2019 +0000

    testcrypt: fix a technically illegal forward-typedef.

    Every compiler that's so far seen testcrypt.c has tolerated me writing
    'typedef enum ValueType ValueType' before actually saying what 'enum
    ValueType' is, but one just pointed out that it's not actually legal
    standard C to do that. Moved the typedef to after the enum.

 testcrypt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

commit fdc480066929bebfc8c86f4ea1438569f27b57ff
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=fdc480066929bebfc8c86f4ea1438569f27b57ff;hp=2a365bb08ac308b7068b99d80938ec4c5a027593
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 11 06:25:28 2019 +0000

    Build testcrypt on Windows.

    The bulk of this commit is the changes necessary to make testcrypt
    compile under Visual Studio. Unfortunately, I've had to remove my
    fiddly clever uses of C99 variadic macros, because Visual Studio does
    something unexpected when a variadic macro's expansion puts
    __VA_ARGS__ in the argument list of a further macro invocation: the
    commas don't separate further arguments. In other words, if you write

      #define INNER(x,y,z) some expansion involving x, y and z
      #define OUTER(...) INNER(__VA_ARGS__)
      OUTER(1,2,3)

    then gcc and clang will translate OUTER(1,2,3) into INNER(1,2,3) in
    the obvious way, and the inner macro will be expanded with x=1, y=2
    and z=3. But try this in Visual Studio, and you'll get the macro
    parameter x expanding to the entire string 1,2,3 and the other two
    empty (with warnings complaining that INNER didn't get the number of
    arguments it expected).

    It's hard to cite chapter and verse of the standard to say which of
    those is _definitely_ right, though my reading leans towards the
    gcc/clang behaviour. But I do know I can't depend on it in code that
    has to compile under both!

    So I've removed the system that allowed me to declare everything in
    testcrypt.h as FUNC(ret,fn,arg,arg,arg), and now I have to use a
    different macro for each arity (FUNC0, FUNC1, FUNC2 etc). Also, the
    WRAPPED_NAME system is gone (because that too depended on the use of a
    comma to shift macro arguments along by one), and now I put a custom C
    wrapper around a function by simply re-#defining that function's own
    name (and therefore the subsequent code has to be a little more
    careful to _not_ pass functions' names between several macros before
    stringifying them).

    That's all a bit tedious, and commits me to a small amount of ongoing
    annoyance because now I'll have to add an explicit argument count
    every time I add something to testcrypt.h. But then again, perhaps it
    will make the code less incomprehensible to someone trying to
    understand it!

 Recipe             |   5 +-
 test/testcrypt.py  |   7 +-
 testcrypt.c        |  93 ++++++++++------
 testcrypt.h        | 320 ++++++++++++++++++++++++++---------------------------
 windows/winmiscs.c |  12 ++
 5 files changed, 237 insertions(+), 200 deletions(-)

commit 80f2f6e7aff423bbb3859c1c0db564c06b044ae1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=80f2f6e7aff423bbb3859c1c0db564c06b044ae1;hp=fdc480066929bebfc8c86f4ea1438569f27b57ff
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 11 07:20:27 2019 +0000

    Fix mp_mul_add_simple on Visual Studio.

    I had forgotten that my VS implementation of BignumADC expected the
    carry parameter to be a literal carry _flag_, i.e. a boolean, rather
    than a full word of extra data to be added to the sum of the main
    input BignumInts a,b. So in one place where I didn't need a separate
    carry I had passed one of the data words in the carry slot, which
    worked fine on gcc and clang, but VS normalised that argument to 1.

    That looks like the only VS bug, though: now I get a clean run of
    cryptsuite.py even if it's talking to a VS-built testcrypt.exe.

 mpint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)