Skip to content

C
ccan
Switch branch/tag
  1. 04 Mar, 2019 4 commits
  3. 28 Feb, 2019 3 commits
  5. 13 Feb, 2019 1 commit
  7. 07 Feb, 2019 1 commit
  9. 05 Feb, 2019 1 commit
  11. 17 Dec, 2018 1 commit
  13. 12 Nov, 2018 1 commit
  15. 05 Nov, 2018 1 commit
    • Dmitry Petukhov's avatar
      small fix for ccan/take/take.c · 440efa55
      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 ]
      440efa55
  17. 02 Nov, 2018 2 commits
  19. 18 Oct, 2018 1 commit
  21. 12 Oct, 2018 4 commits
  23. 27 Sep, 2018 1 commit
  25. 26 Sep, 2018 1 commit
  27. 17 Sep, 2018 2 commits
  29. 23 Aug, 2018 1 commit
  31. 10 Aug, 2018 1 commit
  33. 27 Jul, 2018 5 commits
    • Rusty Russell's avatar
      tal/str: always create strings which have tal_count() == strlen() + 1. · 55d81423
      Rusty Russell authored 
      This is least-surprise, but also means callers can sometimes do faster
string handling by avoiding strstr().
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      55d81423
    • Rusty Russell's avatar
      ccan/tal: always include a length field. · 1651e25e
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      1651e25e
    • Rusty Russell's avatar
      tal/str and tal/stack: use _label interfaces. · 38ec541c
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      38ec541c
    • Rusty Russell's avatar
      tal: add _label interfaces. · ed39cbbd
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      ed39cbbd
    • Rusty Russell's avatar
      tal: rename tal_len to tal_bytelen. · 2cd5e81d
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      2cd5e81d
  35. 04 Jul, 2018 1 commit
  37. 18 Jun, 2018 1 commit
  39. 12 Jun, 2018 7 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7