- 01 Apr, 2019 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 16 Mar, 2019 3 commits
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Free the internal "always" array like we free "fds". Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Suggested-by: Lisa Neigut <@niftynei> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 04 Mar, 2019 5 commits
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
malloc and free aren't for everyone. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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>
-
- 28 Feb, 2019 3 commits
-
-
Rusty Russell authored
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>
-
Rusty Russell authored
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 authored
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>
-
- 13 Feb, 2019 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 07 Feb, 2019 1 commit
-
-
Rusty Russell authored
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>
-
- 05 Feb, 2019 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 17 Dec, 2018 1 commit
-
-
Rusty Russell authored
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>
-
- 12 Nov, 2018 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 05 Nov, 2018 1 commit
-
-
Dmitry Petukhov authored
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 ]
-
- 02 Nov, 2018 2 commits
-
-
Rusty Russell authored
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 authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 18 Oct, 2018 1 commit
-
-
Rusty Russell authored
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>
-
- 12 Oct, 2018 4 commits
-
-
Rusty Russell authored
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>
-
Rusty Russell authored
We should use rbuf primitives not reach inside to membuf. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Clean up some whitespace while we're there too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 27 Sep, 2018 1 commit
-
-
Rusty Russell authored
And change semantics: a negative number means "up to this much padding". Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 26 Sep, 2018 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 17 Sep, 2018 2 commits
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 23 Aug, 2018 1 commit
-
-
Rusty Russell authored
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>
-
- 10 Aug, 2018 1 commit
-
-
Kazuhiro Sera authored
-
- 27 Jul, 2018 5 commits
-
-
Rusty Russell authored
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>
-
Rusty Russell authored
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 authored
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 authored
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 authored
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>
-
- 04 Jul, 2018 1 commit
-
-
Rusty Russell authored
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>
-
- 18 Jun, 2018 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 12 Jun, 2018 2 commits
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-