[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd198a2b-9a79-b7b7-3cee-5856cffc88af@embeddedor.com>
Date: Tue, 16 Jun 2020 15:48:51 -0500
From: "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To: Kees Cook <keescook@...omium.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] overflow.h: Add flex_array_size() helper
On 6/10/20 16:38, Kees Cook wrote:
>> -#define struct_size(p, member, n) \
>> - __ab_c_size(n, \
>> +#define struct_size(p, member, count) \
>> + __ab_c_size(count, \
>> sizeof(*(p)->member) + __must_be_array((p)->member),\
>> sizeof(*(p)))
>
> I like the "count" change -- "n" can be seen as either count or bytes,
> so I like this being distinctly "count".
>
Yep. :)
>>
>> +/**
>> + * flex_array_size() - Calculate size, in bytes, of a flexible array member
>> + * within an enclosing structure. Read on for more details.
>> + *
>> + * @p: Pointer to the structure.
>> + * @member: Name of the flexible array member.
>> + * @count: Number of elements in the array.
>> + *
>> + * Calculates size, in bytes, of a flexible array @member of @count elements
>> + * within structure @p.
>> + *
>> + * Return: number of bytes needed or SIZE_MAX on overflow.
>> + */
>> +#define flex_array_size(p, member, count) \
>> + array_size(count, \
>> + sizeof(*(p)->member) + __must_be_array((p)->member))
>> +
>> #endif /* __LINUX_OVERFLOW_H */
>
> I like it! You mentioned off-list that maybe this could be named
> sizeof_flex_array() (like sizeof_field(), etc), and that does seem
> attractive. As you also mentioned, it begs the question of renaming
> struct_size() to sizeof_struct().
>
> Looking back through the thread[1], it seems the name came from Linus[2],
> and was more related to the existing array_size() helper.
>
> So, how about this, as a convention we can use to make a choice:
>
> For things that are strictly constant in size, we can use sizeof_*. For
> things that have a dynamic component, we'll use *_size(). So, this patch
> is correct as-is.
>
I like the idea. I haven't thought it in terms of dynamic and constant size,
but it sounds sensible.
> Acked-by: Kees Cook <keescook@...omium.org>
>
> (I wonder who's tree this should go via?)
>
Yours? :)
> -Kees
>
> [1] https://lore.kernel.org/lkml/20180507113902.GC18116@bombadil.infradead.org/
> [2] https://lore.kernel.org/lkml/CA+55aFy8DSRoUvtiuu5w+XGOK6tYvtJGBH-i8i-y7aiUD2EGLA@mail.gmail.com/
>
--
Gustavo
Powered by blists - more mailing lists