On 08/02/16 10:45, Rusty Russell wrote: > [email protected] writes: >> From: Stuart Longland <[email protected]> >> >> This provides a way for btree to be used with external allocator >> libraries such as the tal or talloc modules. > > Sure. In my libraries I generally use a global allocator override; > it's not thread-safe, but much easier to use in practice. > > Since I don't use btree, I'm agnostic about it though!
Indeed, actually I'm half considering whether we make it a separate
module that `btree` (and others) can pull into their code. There are
lots of cases where `tal` or `talloc` is desirable over the standard C
malloc/free.
> Minor nits below:
> …
>> /*
>> * If iter->node has parent, returns 1 and ascends the iterator such that
>> @@ -65,11 +68,19 @@ static int node_walk_forward(const struct btree_node
>> *node,
>>
>> struct btree *btree_new(btree_search_t search)
>> {
>> - struct btree *btree = calloc(1, sizeof(struct btree));
>> - struct btree_node *node = node_alloc(0);
>> + return btree_new_with_alloc(search, &BTREE_DEFAULT_ALLOCATOR);
>> +}
>> +
>> +struct btree *btree_new_with_alloc(btree_search_t search,
>> + const struct btree_allocator *alloc)
>> +{
>> + struct btree *btree = (*(alloc->malloc))(alloc, sizeof(struct btree));
>
> You can call a function pointer, so alloc->malloc(alloc, sizeof(struct
> btree));
> should work.
Ahh, didn't know about that. I presume a more recent C standard? I'll
admit I had to look up the syntax for function pointers off Wikipedia as
I don't do it often enough.
(In fact, I don't do *C* often enough.)
> Lots of whitespace cleanups. Not a problem, but prefer a separate patch
> for clarity.
Yep, I often do a whitespace cleanup first up and ordinarily do that as
a first commit. I'll split these out.
> Put default_malloc and default_free above the BTREE_DEFAULT_ALLOCATOR
> definition, and you don't need to pre-declare them.
Will do.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ccan mailing list [email protected] https://lists.ozlabs.org/listinfo/ccan
