Rusty Russell [Fri, 17 Jul 2020 01:56:51 +0000 (11:26 +0930)]
tools/configurator: fix compile error with -O2
In file included from /usr/include/string.h:495,
from configuratortest.c:2:
In function ‘strncpy’,
inlined from ‘main’ at configuratortest.c:6:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound 8 equals destination size [-Wstringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell [Mon, 17 Feb 2020 00:12:46 +0000 (10:42 +1030)]
tal: don't defer-after-free if a destructor deletes itself.
==10868== at 0x109A96: notify (tal.c:220)
==10868== by 0x109F7E: del_tree (tal.c:397)
==10868== by 0x10A31A: tal_free (tal.c:481)
==10868== by 0x10BE73: main (run-destructor.c:75)
==10868== Address 0x4a60bd8 is 8 bytes inside a block of size 32 free'd
==10868== at 0x483BA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==10868== by 0x109D4F: del_notifier_property (tal.c:340)
==10868== by 0x10A610: tal_del_notifier_ (tal.c:564)
==10868== by 0x10A687: tal_del_destructor_ (tal.c:576)
==10868== by 0x10B653: remove_own_destructor (run-destructor.c:35)
==10868== by 0x109A67: notify (tal.c:235)
==10868== by 0x109F7E: del_tree (tal.c:397)
==10868== by 0x10A31A: tal_free (tal.c:481)
==10868== by 0x10BE73: main (run-destructor.c:75)
==10868== Block was alloc'd at
==10868== at 0x483A7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==10868== by 0x109AD5: allocate (tal.c:245)
==10868== by 0x109C3E: add_notifier_property (tal.c:300)
==10868== by 0x10A467: tal_add_destructor_ (tal.c:516)
==10868== by 0x10BDFE: main (run-destructor.c:74)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell [Tue, 11 Feb 2020 04:09:43 +0000 (14:39 +1030)]
opt: fix opt_unregister.
Instead of memmoving N structs, we were memmoving N bytes.
But why did the test pass then? It was doing memmove(..., 1)
instead of memmove(..., sizeof(struct opt_table)!
Because the two structures were really similar; the main difference
was the first entry, which points to the name. But they were allocated
consecutively, and Intel being little-endian, the only difference was
the first byte! Thus memmove(1) was enough to make it "work".
Change two options in the test to be sufficiently different, and
the bug shows up.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Niklas Claesson [Tue, 28 Jan 2020 23:50:15 +0000 (00:50 +0100)]
configurator: Enable running configurator in wrapper
Since the probing binaries compiled by the configurator needs to run on
the host machine we provide a variable CONFIGURATOR_WRAPPER that can be
set to anything that you want to wrap the calls with.
Kirill Smelkov [Mon, 21 Oct 2019 15:09:20 +0000 (15:09 +0000)]
bitmap: Allow bitmap type to be forward declared
Currently bitmap type is defined via untagged struct which makes it
impossible to forward declare it. Forward-declaring is useful since all
bitmap functions only use bitmap* and in public user-visible
headers/datastructures it is enough to indicate that a data field with
bitmap pointer is there, whereas bitmap.h can be included only in
implementation.
Beside that some headers are included by both C and C++ parts of a
project, and when ccan/bitmap.h is processed by C++ compiler it gives:
./3rdparty/ccan/ccan/bitmap/bitmap.h: In function ‘bitmap* bitmap_alloc(long unsigned int)’:
./3rdparty/ccan/ccan/bitmap/bitmap.h:201:15: error: invalid conversion from ‘void*’ to ‘bitmap*’ [-fpermissive]
return malloc(bitmap_sizeof(nbits));
~~~~~~^~~~~~~~~~~~~~~~~~~~~~
./3rdparty/ccan/ccan/bitmap/bitmap.h: In function ‘bitmap* bitmap_realloc0(bitmap*, long unsigned int, long unsigned int)’:
./3rdparty/ccan/ccan/bitmap/bitmap.h:227:18: error: invalid conversion from ‘void*’ to ‘bitmap*’ [-fpermissive]
bitmap = realloc(bitmap, bitmap_sizeof(nbits));
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./3rdparty/ccan/ccan/bitmap/bitmap.h: In function ‘bitmap* bitmap_realloc1(bitmap*, long unsigned int, long unsigned int)’:
./3rdparty/ccan/ccan/bitmap/bitmap.h:238:18: error: invalid conversion from ‘void*’ to ‘bitmap*’ [-fpermissive]
bitmap = realloc(bitmap, bitmap_sizeof(nbits));
-> Give to users ability not to force-include ccan/bitmap.h by
forward-declaring bitmaps like this:
David Gibson [Thu, 11 Jul 2019 02:07:33 +0000 (12:07 +1000)]
bitmap: Fix some bugs on 32-bit platforms
The bitmap_word type is an unsigned long. However in some places we assign
it using -1ULL, a 64-bit value on many platforms. We sometimes get away
with this because it masks correctly, but in other cases it breaks things.
To clean this up define a new BITMAP_WORD_1 constant, indicating a
bitmap_word with all bits set, and use that instead of explicit UL or ULL
qualifiers.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rusty Russell [Fri, 1 Mar 2019 01:43:35 +0000 (12:13 +1030)]
ccan/io: add io_conn_exclusive and io_conn_out_exclusive.
There are cases where we want to suppress all activity except for a
single fd; we already have ugly io_flush_sync, but this is more
useful and more general.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell [Thu, 28 Feb 2019 05:25:29 +0000 (15:55 +1030)]
ccan/io: keep always pointers to plans, not a linked list.
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>
Rusty Russell [Mon, 17 Dec 2018 00:16:32 +0000 (10:46 +1030)]
tal: handle take() pointers more carefully.
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>
Dmitry Petukhov [Sun, 4 Nov 2018 14:58:04 +0000 (19:58 +0500)]
small fix for ccan/take/take.c
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.
Rusty Russell [Fri, 2 Nov 2018 01:27:57 +0000 (11:57 +1030)]
opt: add new parse_early_args_incomplete.
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>
Rusty Russell [Thu, 23 Aug 2018 02:41:13 +0000 (12:11 +0930)]
tal: allow notifiers on NULL.
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>
Rusty Russell [Fri, 27 Jul 2018 04:29:18 +0000 (13:59 +0930)]
ccan/tal: always include a length field.
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>
Rusty Russell [Fri, 27 Jul 2018 04:23:19 +0000 (13:53 +0930)]
tal/str and tal/stack: use _label interfaces.
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>
Rusty Russell [Fri, 27 Jul 2018 04:22:20 +0000 (13:52 +0930)]
tal: add _label interfaces.
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>
Rusty Russell [Wed, 4 Jul 2018 04:07:28 +0000 (13:37 +0930)]
ccan/structeq: make it safe when there's padding.
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>
Rusty Russell [Thu, 10 May 2018 02:25:59 +0000 (11:55 +0930)]
endian: fix compilation with musl libc.
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>
gcc6 introduceed a new warning switched with -Wmisleading-identation. This caused to generate a compilation warning for if statement misleadingly indented, which caused HAVE_ASPRINTF to be defined as 0. Adding newline after an if statement fixes the problem.
Rusty Russell [Mon, 26 Mar 2018 10:36:34 +0000 (21:06 +1030)]
intmap: reimplement so that intmap_after works.
A critbit tree is a binary tree which keeps branches for each bit
which differs in the leaves. It's a simple data structure, but not
entirely simple to implement the primitives people expect, as this bus
shows.
The bug: I added an open iterator, and intmap_after_ for a random
value would sometimes return the wrong node.
Cause: we don't know what the prefix is as we iterate, so by only
testing the critbits in the tree, we can end up in the wrong place.
This is only a problem if the value isn't in the (sub)tree, but this
can easily happen even with contiguous trees should deletion occur.
You can see an example in the next patch, which adds a test.
After finding a bug in my intmap_after() routine, I went searching for
other implementations to see how they handled it. Most didn't provide
an open-ended iterator like this, relying on callback iterators which
don't allow deletion. Gah!
The exception was https://github.com/blynn/blt/blob/master/blt.c#L179
which implements blt_ceil() which does this (if you add one to the
key, at least). However, it does it by effectively finding a node,
using that to derive the prefix, then walking down the tree again.
That's pretty suboptimal.
There are basically two choices if you want an efficient after()
operation: to reimplement this approach with some optimizations
(ie. keep branches as we descend, and when we get to the bottom and
know the prefix, we know which branch to go down), or keep the bits
which got to each node.
The latter is more optimal, but less generally useful: for bit
strings, for example, we could keep the bits in common on each node,
rather than storing the entire string at the bottom. But in practice
you'd be doing allocations to re-create the index if the caller wanted
it.
However, in this implementation our keys are 64 bits only, and we
already use a u8 for the bit number: using a 64-bit value there
consumes no more space (thanks to alignment). We can store the
critbit by using the prefix capped by a bit: 0b10000...0000 means
no prefix and highest bit is the critbit, and 0bxxxxx1000...000
means the prefix is xxxxxx and the critbit is the 6th highest bit.
The penalty is that iteration 70% slower. It's still pretty fast
though.
Before:
$ for i in `seq 5`; do ./speed 10000000; done | stats 10000000,random generation (nsec),3-4(3.2+/-0.4) 10000000,critbit insert (nsec),1530-1751(1633.2+/-80) 10000000,critbit successful lookup (nsec),1723-1993(1806.8+/-97) 10000000,critbit failed lookup (nsec),1763-2104(1933.6+/-1.3e+02) 10000000,critbit iteration (nsec),208-266(242.2+/-19) 10000000,critbit memory (bytes),48 10000000,critbit delete (nsec),1747-1861(1803.8+/-42) 10000000,critbit consecutive iteration (nsec),182-228(210+/-18)
Yubin Ruan [Mon, 12 Mar 2018 03:24:14 +0000 (11:24 +0800)]
fix misspelling in the example of container_of
From 47c92fe951545e780ca31c598bbcbe5347059b27 Mon Sep 17 00:00:00 2001
From: Yubin Ruan <ablacktshirt@gmail.com>
Date: Mon, 12 Mar 2018 11:22:35 +0800
Subject: [PATCH] fix misspelling in the example of container_of
Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
projects / ccan / log