On 05/22/17 14:43, Joe Perches wrote: > On Tue, 2017-05-23 at 00:38 +0300, Alexey Dobriyan wrote: >> There are valid reasons for >> >> malloc(sizeof(struct S)) >> >> form: >> >> * struct S acts as an anchor for ctags quickly reminding which type is >> in focus >> >> * argument re changing name prevents bugs is semi bogus: >> such changes are rare, >> "void *" cast gives both forms equal opportunity to be screwed up >> >> * proper way to fix those rare misallocation bugs (which indeed happened) >> is type safe allocation macros (see tmalloc from Samba). >> >> However amount of disruption will be so high so it may never be done. >> >> * ratio of allocation styles is ~6400:12000 which is about 1:2 >> so the amount of churn to maintain this rule is pretty high in theory. >> >> The winning move is to not play and not encourage people send trivial stuff. >> >> Signed-off-by: Alexey Dobriyan <adobri...@gmail.com> >> --- >> >> Documentation/process/coding-style.rst | 10 ---------- >> 1 file changed, 10 deletions(-) >> >> --- a/Documentation/process/coding-style.rst >> +++ b/Documentation/process/coding-style.rst >> @@ -808,16 +808,6 @@ kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), >> vmalloc(), and >> vzalloc(). Please refer to the API documentation for further information >> about them. >> >> -The preferred form for passing a size of a struct is the following: >> - >> -.. code-block:: c >> - >> - p = kmalloc(sizeof(*p), ...); >> - >> -The alternative form where struct name is spelled out hurts readability and >> -introduces an opportunity for a bug when the pointer variable type is >> changed >> -but the corresponding sizeof that is passed to a memory allocator is not. >> - >> Casting the return value which is a void pointer is redundant. The >> conversion >> from void pointer to any other pointer type is guaranteed by the C >> programming >> language. > > Thanks. I agree with this deletion. >
Acked-by: Randy Dunlap <rdun...@infradead.org> Thanks. -- ~Randy
