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

So many bugs in one example program!

There was an unrelated but which strace revealed (trying to write -7
bytes), but I think your issue was more prosaic: failing to zero the
from buffer.
Reported-by: Ian Zimmerman <itz@very.loosely.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

An application built using glibc would expect __BYTE_ORDER to tell if
it should be compiled for BIG_ENDIAN or LITTLE_ENDIAN, whereas ccan uses
HAVE_LITTLE_ENDIAN and HAVE_BIG_ENDIAN for the same purpose.

Hence setting __BYTE_ORDER based on what CCAN provides will no longer
break the applications which check endianness the glibc way.
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

I had a case where I was handing a sub-object (not a tal object!) to
tal_steal() and it wasn't detected, because the pointers looked correct.

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

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

The memmove() call should be using the index argument to determine the
number of bytes to copy. To be consistent with the rest of the code,
we should also not evaluate the index parameter multiple
times. Calling this with rand() % arr.size would otherwise generally
segfault.

Finally, we want to avoid using "index" as an identifier so as to not
shadow index(3) in the C library.
Signed-off-by: Damien Grassart <damien@grassart.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Identifiers starting with underscores are technically reserved for
system use, so rename all of them to end with one instead.
Signed-off-by: Damien Grassart <damien@grassart.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

This module currently supports removing but not inserting at a
specified index, so this adds that along with some tests. Inserting a
value moves all existing data beyond index over one element.
Signed-off-by: Damien Grassart <damien@grassart.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

You can use SHACHAIN_BITS to contrain the size.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

TCON() uses flexible-array members which aren't allowed in the middle
of structures, except as a gcc extension.  TCON_WRAP() avoids this and so
is more portable.

This doesn't change the objset interface, only its internals.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

TCON() uses flexible-array members which aren't allowed in the middle
of structures, except as a gcc extension.  TCON_WRAP() avoids this and so
is more portable.

This doesn't change the jmap interface, only its internals.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

TCON() uses flexible-array members which aren't allowed in the middle
of structures, except as a gcc extension.  TCON_WRAP() avoids this and so
is more portable.

This doesn't change the jset interface, only its internals.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

TCON() uses flexible-array members which aren't allowed in the middle
of structures, except as a gcc extension.  TCON_WRAP() avoids this and so
is more portable.

This doesn't change the tlist interface, only its internals.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

It's a common thing to want to do, so add helper here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

If we're duplex and one io_always callback makes the other io_always,
we screwed up and hit an assertion later when the conn was in the
always list but didn't actually want to be.

io_wake() uses io_always(), so this is how it happened.  Writing a
test case for this was a bit fun, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

At this point the construction of the function above means that nn cannot
be NULL.

Found by Coverity Scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

make_listen_fd() didn't check for failure of setsockopt().  There's no
real reason not to, since we have an obvious way to report an error to the
caller.

Found with Coverity Scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

options_avail and options_used get freed, but options does not.

Found by Coverity scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

struct ripemd160_ctx has a union for converting between u8[] and u32[]
data.  Unfortunately the u32 array has a miscalculated size, half the size
of the u8 array.  That means some accesses which are within the union can
technically overrun the u32 array.

Found by Coverity scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

compile_info() can leak an open file descriptor write_all() fails.  This
corrects it.

Found by Coverity.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Somewhat ironically, a path in failtest related to detecting leaks in the
tested program itself leaks memory.  This corrects it.

Detected by Coverity.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

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

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

This corrects several places in ccan where stdarg.h is used but there is a
missing va_end().  You can get away with this on many platforms, but not
all.

Caught by Coverity scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

lbalance uses the tlist module. tlist causes compile warnings on clang if
you're not careful, because it can put 0 length arrays in the middle of
structures.  tlist2 doesn't have the problem, and also has a slightly
cleaner interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

tools/ccanlint/async.c uses kill(2), but doesn't include the signal.h
header it comes from.  One some platforms we get away with this via
indirect includes, but not on all.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

tools/manifest.c uses asort(), but the asort module is not in
TOOLS_CCAN_MODULES.  That causes compile failures on some platforms, so
correct it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

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

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

commit 25b7406d tried to make the tests
depend on the info file, but that broke .fast.ok, which used the same
pattern:

	%.ok: $(LINT) %info

This is what happens when you're too tricky!  Simply duplicate the rule,
and change .fast.ok to .fast-ok so it doesn't match both.
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>

This is needed for emergency handling in lightningd: we want to output
a (fatal) error packet on the socket, but we don't want to do so in the middle
of another packet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Martin Milata <martin@martinmilata.cz>

This enables clang compiler builds for the trusty Travis environment.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

At present, coroutine stacks must be allocated explicitly by the user,
then initialized with coroutine_stack_init().  This adds a new
coroutine_stack_alloc() function which allocates a stack, making life
easier for users.  coroutine_stack_release() will automatically determine
if the given stack was set up with _init() or alloc() and act
accordingly.

The stacks are allocate with mmap() rather than a plain malloc(), and a
guard page is added, so an overflow of the stack should result in a
relatively debuggable SEGV instead of random data corruption.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Currently valgrind checks are disabled on the coroutine module,
because switching stacks tends to confuse it.  We can work around this
by using the valgrind client interface to explicitly inform it about
the stacks we create.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

In preparation for enabling valgrind tests, remove instances where we
allocate a coroutine's stack from a buffer itself on the stack.  Not all
that surprisingly, valgrind gets very, very confused by having one
"thread"'s stack embedded within another's.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>