Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

I tried to use it and got this wrong: moreover, I wanted to control
topology, which requires nested iteration, and skip children
of a node which I knew was changing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This largely follows the SHA256 style. I've named Rusty as the maintainer.

Currently the functions to add data of various sizes/endianness have not
been implemented: There are no public test vectors for these cases and
I believe most use cases are working on byte buffers. They can be added
later if desired.

The openssl implementation has been tested on x86-64, while the inbuilt
version has been tested on 32/64 bit, little/big endian boxes.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Jon sent a test patch for sha256 which "#include <ccan/str/hex/hex.c>"
without adding str/hex to testdepends.  It "worked" (it wouldn't have
linked with "hex.h"), but ccanlint didn't spot the dependency.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Users should be able to verify our crypto tests by searching for the
vectors we use. Make that easier by using hex for the expected results.

A nice side effect is that the code is simpler and endian agnostic too.

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Keys are never modified and are likely to be literals in the
real world (as they are in the test cases).
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Unsigned types cannot be negative.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

This matches the license in _info and the source. It also means every
module now has a LICENSE file and so anyone happening to rewrite the
ccan makefiles can use wildcard to locate modules rather than listing
them by hand.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

clang warns that the generator assignment is conditional which could
lead to passing an undefined variable to printf.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

The current makefiles are not parallel safe and reliably fail on the
clang build. The real fix is to rewrite the makefiles, but in the
meantime, allow the clang tests to pass.

We can use the iteration count in the test case to determine
whether a single call is required. This simplifies the code and
also means that we don't overstate the actual number of tests
performed by a factor of 2. Simplify a couple of expressions
while we are changing this.

TCON suggests placing _tcon members last in structs. Placing variable
sized structs anywhere but last is apparently a gcc extension that
gives warnings under clang.

This applies to tlists because they use TCON internally. Update the
docs and examples to place tlists last and so compile without clang
warnings.

There are other places where this occurs; they will be dealt with
separately.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Running 'tools/ccan_depends --compile ccan/crypto' without this
patch will demonstrate the crash.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Closes: 47

Closes: 46

Closes: 45

The header macro RIPEMD160_INIT is intended to be used instead I believe.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

The resulting code is just as clear to read, so lets not require
a C99 compiler to compile this.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

The documentation for hex_encode indicates that it returns simply true or
false. The old implementation was returning the written length on success,
cast to boolean. This will elicit a warning under MSVC.

On further examination, there is no need to check/modify the length inside
the loop, since we can check it once before starting. As a result the code
can be simplified a bit.

A side affect of this change is that nothing will be written at all if the
length is incorrect, vs the previous code writing characters until the length
available is exhausted. I prefer the new semantics but YMMV.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Show the derivation of the constants to match the comment above them.
The compiler doesn't care, but it helps the code read better.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

The code already assigns to/from bytes as a size_t, so make it
official (and better on platforms with a 32 bit size_t).

Moving bytes makes it act as a canary in the event that there is a rogue
write/off by one somewhere - since it ends up in the hash we are
more likely to detect this should we corrupt it. This also makes the
working buffer better aligned which can't hurt.

Also, initialise the buffer to zero while we are changing the initialisation
macro anyway. It costs little compared to the hashing overhead, should be
optimised away if redundant in most cases, and it removes a warning from both
gcc and clang about unititialised struct members.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

This reads better. Also remove duplicated comments for the members.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

These are just aliases to a buffer: its customary for these to
have the same size, and makes sizeof() consistent in case anyone
decides to use the members instead of the containing union.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Prevents warnings from gcc at higher warning levels.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Prevents warnings from gcc at higher warning levels.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Prevents warnings from gcc at higher warning levels.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

altstack/test/run.c uses some hairy macros to intercept the standard
library functions that altstack uses.  This has two purposes: 1) to
conditionally cause those functions to fail, and thereby test altstack's
error paths, and 2) log which of the library functions was called in each
testcase.

The second function isn't actually useful - for the purposes of testing the
module, we want to check the actual behaviour, not what calls it made in
what order to accomplish it.  Explicitly checking the calls makes it much
harder to change altstack's implementation without breaking the tests.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

In a number of places the altstack module uses a literal '0' for pointer
values.  That's correct C, but doesn't make it obvious on a quick read
whether values are integers or pointers.  This patch changes those cases
to use the NULL define instead.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>