This is the same as list_empty but without the debug checks. This is
useful when wanting to check for an empty list without locks held,
potentially racing with addition/removal, which can be a valid thing
to do under some circumstances.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

This causes ccanlint to fail the 'no warnings' check under clang.
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>

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

Useful for scanning all the memory, or tallying it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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>