Skip to content

C
ccan
Switch branch/tag
  1. 19 Jun, 2020 1 commit
  3. 20 Feb, 2020 2 commits
  5. 19 Feb, 2020 1 commit
  7. 17 Feb, 2020 1 commit
    • Rusty Russell's avatar
      tal: don't defer-after-free if a destructor deletes itself. · c910bdce
      Rusty Russell authored 
      ==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: default avatarRusty Russell <rusty@rustcorp.com.au>
      c910bdce
  9. 11 Feb, 2020 1 commit
    • Rusty Russell's avatar
      opt: fix opt_unregister. · 4f20b75c
      Rusty Russell authored 
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      4f20b75c
  11. 04 Feb, 2020 4 commits
  13. 22 Oct, 2019 1 commit
    • Kirill Smelkov's avatar
      bitmap: Allow bitmap type to be forward declared · 39b46a02
      Kirill Smelkov authored 
      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:

    typedef struct bitmap bitmap;
    ...
    struct MyStruct {
        bitmap *my_bitmap;
    };

Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Kirill Smelkov's avatarKirill Smelkov <kirr@nexedi.com>
Message-Id: <20191021150903.25159-1-kirr@nexedi.com>
Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      39b46a02
  15. 10 Oct, 2019 1 commit
  17. 04 Oct, 2019 1 commit
  19. 14 Aug, 2019 1 commit
  21. 13 Aug, 2019 1 commit
  23. 01 Aug, 2019 1 commit
  25. 31 Jul, 2019 1 commit
  27. 11 Jul, 2019 1 commit
    • David Gibson's avatar
      bitmap: Fix some bugs on 32-bit platforms · cdd0b8b5
      David Gibson authored 
      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: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      cdd0b8b5
  29. 11 Jun, 2019 4 commits
  31. 23 May, 2019 1 commit
  33. 22 May, 2019 1 commit
  35. 21 May, 2019 2 commits
  37. 02 Apr, 2019 1 commit
    • Rusty Russell's avatar
      htable: avoid branch in calculating perfect bit. · 7623d082
      Rusty Russell authored 
      Final results of tools/speed/10000000 (10 runs) shows a slight
slowdown in some tests, but it makes an empty htable smaller.

-Initial delete all: 96-98(96.4+/-0.66) ns
+Initial delete all: 97-99(98.2+/-0.75) ns
-Initial re-inserting: 117-124(121.4+/-1.9) ns
+Initial re-inserting: 124-131(126.4+/-2.4) ns
-Adding (a different) half: 49-50(49.3+/-0.46) ns
+Adding (a different) half: 50-52(51.2+/-0.75) ns
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      7623d082
  39. 01 Apr, 2019 2 commits
  41. 16 Mar, 2019 3 commits
  43. 04 Mar, 2019 5 commits
  45. 28 Feb, 2019 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7