[ccan] [PATCH] btree: Add custom allocator interface.

Stuart Longland stuartl at longlandclan.id.au
Tue Feb 9 13:14:59 AEDT 2016


On 09/02/16 09:40, David Gibson wrote:
> On Mon, Feb 08, 2016 at 02:26:29PM +1000, Stuart Longland wrote:
>> On 08/02/16 12:17, David Gibson wrote:
>>>> +static void* default_malloc(const struct btree_allocator* alloc, size_t size);
>>> Existing style in this function suggests "void *foo" rather than
>>> "void* foo".
>>
>> Ahh, call it habit, I'm used to having the "pointer" bit with the type
>> (as to me; "pointer to void" is a distinct type from "void").  Caught
>> myself doing it elsewhere but missed it here, I'll fix it.
> 
> So, from a language design point of view, I agree with you.  However,
> I dislike that style in C because it obscures the fact that C
> importantly *does not* have that sensible handling of types.
> 
> More specifically this style:
>     int*  a, b;
> 
> Suggests that a and b have the same type, but of course they don't.

Yeah, for that reason I tend to write:
int* a;
int* b;

thus being explicit about it.  In fact I do that for non-pointers too as
it's just clearer.  (I'd make lousy submissions to the IOCCC.)

It also lets me document what each variable is doing with a comment.

However, we digress, the style is definitely the 'void *foo' style
already, and so in the interests of code consistency, that shall be the
style used. ;-)

>>> [snip]
>>>>> +/* Default allocator implementation */
>>>>> +const struct btree_allocator BTREE_DEFAULT_ALLOCATOR = {
>>> Use of all-caps for a non-macro is a bit unexpected.
>>>
>>
>> Good point.  I guess I wanted to visually differentiate a constant from
>> other member types.
> 
> I applaud the idea, but unfortunately I don't think that use of caps
> is common enough to make it really clear.

Yeah, I did it without thinking, elsewhere like in Python, that's the
convention; ALL_CAPS → constant.  I know C has a convention for macros
being capitalised, but none really for const members, my fingers just
went on autopilot.

I shall fix this though when I get to everything else. :-)

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/ccan/attachments/20160209/2530c2d0/attachment.sig>


More information about the ccan mailing list