Skip to content

C
ccan
Switch branch/tag
  1. 04 Feb, 2020 4 commits
  3. 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
  5. 10 Oct, 2019 1 commit
  7. 04 Oct, 2019 1 commit
  9. 14 Aug, 2019 1 commit
  11. 13 Aug, 2019 1 commit
  13. 01 Aug, 2019 1 commit
  15. 31 Jul, 2019 1 commit
  17. 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
  19. 11 Jun, 2019 4 commits
  21. 23 May, 2019 1 commit
  23. 22 May, 2019 1 commit
  25. 21 May, 2019 2 commits
  27. 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
  29. 01 Apr, 2019 2 commits
  31. 16 Mar, 2019 3 commits
  33. 04 Mar, 2019 5 commits
  35. 28 Feb, 2019 3 commits
  37. 13 Feb, 2019 1 commit
  39. 07 Feb, 2019 1 commit
  41. 05 Feb, 2019 1 commit
  43. 17 Dec, 2018 1 commit
  45. 12 Nov, 2018 1 commit
  47. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7