lkml.org 
[lkml]   [2017]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch
Date
On 01/06/17 09:02, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 11:52:07PM +0000, Junichi Nomura wrote:
>>>> + p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
>>>
>>> Perhaps sizeof(*p) ?
>>
>> Yeah, that might be preferred.
>
> No, those things are never preferred because
>
> sizeof(struct <type>)
>
> tells you exactly the size of what kind of object you're getting vs
>
> sizeof(*p)
>
> which tells you you're getting the size of what p points to.
>
> Now you have to go look at p and what type it is. In the current case, p
> is defined not far away from the use site but in a larger function, you
> most likely need to eyeball up to its type when reading the code. Which
> makes the whole thing less readable.

Personally I have same opinion as yours. :)

But according to Documentation/process/coding-style.rst, it seems
"sizeof(*p)" is preferred style and the reason there makes some
sense.

Quote from coding-style.rst:
> The preferred form for passing a size of a struct is the following:
>
> 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.

I'm fine with either way.

--
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
\
 
 \ /
  Last update: 2017-01-06 01:19    [W:0.050 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site