We could just make them -1, since we don't rely on the values.
But simple negation doesn't make 0 invalid.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Duplex io_conns can be in the always list twice, and it was a source
of bugs, but I didn't want to add a second list_node.  Since there are
not many always at once, it's better (and more space-efficient) to use
a simple pointer array.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

io_conn contains two plans: by knowing what plan this is, it can be cast
back into the io_conn.  That helps for the next patch.

We also remove the strange logic where io_duplex() would return a
magic, invalid io_plan pointer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

This was reported and fixed by @m-schmoock for stderr, but I decided to
rework to make it clearer and cover the other cases:

	https://github.com/ElementsProject/lightning/pull/2321/commits/67dad01549f876e5e620eeffe2f1e78c35bd0f03Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

take() applies to the literal pointer value, so tal_free() means it may
randomly apply to a future allocation.  Similarly, tal_resize() should
preserve it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

Hello.

I've decided to take a look at c-lighting code, because we might
consider using it in the future.

I found a small problem in ccan/take/take.c that only concerns code
that runs with CCAN_TAKE_DEBUG set (DEVELOPER=1 for c-lighting).

It is a small issue, but I decided to notify you as the author of the
code, anyway.

the issue is:
  in take_() function, potential failure of realloc for labelarr is not
  handled.

I attached a diff with a fix.

I thought that making a pull request for c-lighting would not be right,
as ccan is a separate project, but I did not find a way to report this
at http://git.ozlabs.org/, where ccan repo resides.

Therefore I wrote to you directly.

[ Minor whitespace changes --RR ]

If we have plugins, and those can register args, we have a problem finding
the plugin dir!  So, do a best-effort incomplete parse.

Note that this can screw up in theory if we have "--unknown --foo" since we
don't know if unknown takes an argument (in which case, ignore --foo) or
not.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

It's used inside io_finish; setting to 0 allows that to know we hit
EOF on a read.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Trying to debug what looked like an htable fail in my own code (but seems
it's not), I added htable_check a-la list_check et al.

This means we now depend on ccan/str (for stringify), which breaks the
_info example which also defined streq, and played nasty with const pointers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We should use rbuf primitives not reach inside to membuf.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Clean up some whitespace while we're there too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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

And change semantics: a negative number means "up to this much padding".
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>

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

A destructor on NULL doesn't make sense, but notifiers (eg. new children)
do.  We fix up a mistake in run-notifier (comparing ctx with itself) and
loose typing in tal.c's tal_add_notifier_ too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is least-surprise, but also means callers can sometimes do faster
string handling by avoiding strstr().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The current semantics of tal_count() / tal_bytelen() are to return 0
for anything not allocated using tal_arr*.  This is because we tried
to save a native-length word in the header, but produces an awkward
API.

(To make it worse, defining CCAN_TAL_DEBUG turns length to always on,
and we enable that for c-lightning developer mode, which hides bugs!).

However, for c-lightning, just over half of allocations want a length:
these use 3 words each, so we're actually worse off overall.

The answer is to always have a length field in the header.  This also
simplfies the tal code.

samba-allocs stats before:
Tal time: 1237102-1305755(1.251e+06+/-2.1e+04)ns
Tal_free time: 1346871-1514514(1.37844e+06+/-5.2e+04)ns

After:
Tal time: 1115180-1180633(1.1351e+06+/-2.1e+04)ns
Tal_free time: 1334381-1465933(1.39148e+06+/-4.7e+04)ns
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

In particular, tal/str now passes through the label from the caller,
so (in case of CCAN_TAL_DEBUG) you can actually see the file and line
where the caller was, not just inside ccan/str.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

There are a number of other utilities which use the tal_alloc_ and
tal_dup_arr_ internal interfaces directly, because they want to set
the label themselves.  We're about to break them all by changing those
internal interfaces, so give them a mid-level interface to use.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

I had a bug caused by using tal_len instead of tal_count: let's make
it explicit. @jb55 commented "ha. I always forget which one does which... Ack"
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

ccan/cppmagic FTW!

The only issue is that we can't tell if there's padding or they've missed
a member, so we add a padding bytes count, so they'll get an error if it
(for example) the structure adds a new member later.
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>

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

Groundwork for adding tests dynamically.
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>

Works well with --autotools-style.
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 the only non-text field.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

I don't see likely/unlikely being used by ccan/timer or any of its
dependencies right now.

Running `tools/ccanlint/ccanlint ccan/timer' reveals no regressions
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

It defines __BYTE_ORDER to __BYTE_ORDER__; gcc complains when we define
it to something else.  Let it be already defined, but check that the
value is what we expect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>