lkml.org 
[lkml]   [2016]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH v3 24/33] radix-tree: Add radix_tree_split
    Date
    From: Randy Dunlap [mailto:rdunlap@infradead.org]
    > > +void radix_tree_iter_replace(struct radix_tree_root *,
    > > + const struct radix_tree_iter *, void **slot, void *item);
    >
    > > +int radix_tree_split(struct radix_tree_root *, unsigned long index,
    > > + unsigned new_order);
    >
    > and above:
    >
    > As indicated in CodingStyle:
    > In function prototypes, include parameter names with their data types.
    > Although this is not required by the C language, it is preferred in Linux
    > because it is a simple way to add valuable information for the reader.

    I think the rule here should be a bit more nuanced. I think it is positively criminal to have an unnamed 'unsigned long' or 'bool' in a function prototype. But what extra information is communicated by adding 'root' after 'struct radix_tree_root *'? I know it's a root, you told me that with the structure name!

    Obviously sometimes it would be useful, for example if we had a function to move an entry from one radix tree to another, you might want to have 'struct radix_tree_root *old, struct radix_tree_root *new' as two of your parameters.

    > > int radix_tree_join(struct radix_tree_root *, unsigned long index,
    > > unsigned new_order, void *);
    >
    > Yes, the source file already omits some function prototype parameter names,
    > so these patches just follow that tradition. It's weird (to me) though that
    > the existing code even mixes this style in one function prototype (see
    > immed. above).

    I agree that void * should probably be named (as new_entry). Naming index and new_order is correct. But again, there's no useful information given by naming root.
    \
     
     \ /
      Last update: 2016-11-29 16:00    [W:5.207 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site