Re: [PATCH v2] build_bug.h: more user friendly error messages in BUILD_BUG_ON_ZERO()

[Vincent Mailhol]

+To: Yury Norov

On 09/04/2025 at 04:03, Kees Cook wrote:
> On Tue, Apr 08, 2025 at 10:23:53PM +0900, Vincent Mailhol wrote:
>> On 08/04/2025 at 01:46, Kees Cook wrote:
>>> On Sat, Mar 29, 2025 at 01:48:50AM +0900, Vincent Mailhol wrote:
>>>> __BUILD_BUG_ON_ZERO_MSG(), as introduced in [1], makes it possible to
>>>> do a static assertions in expressions. The direct benefit is to
>>>> provide a meaningful error message instead of the cryptic negative
>>>> bitfield size error message currently returned by BUILD_BUG_ON_ZERO():
>>>>
>>>>   ./include/linux/build_bug.h:16:51: error: negative width in bit-field '<anonymous>'
>>>>      16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
>>>>         |                                                   ^
>>>>
>>>> Get rid of BUILD_BUG_ON_ZERO()'s bitfield size hack. Instead rely on
>>>> __BUILD_BUG_ON_ZERO_MSG() which in turn relies on C11's
>>>> _Static_assert().
>>>>
>>>> Use some macro magic, similarly to static_assert(), to either use an
>>>> optional error message provided by the user or, when omitted, to
>>>> produce a default error message by stringifying the tested
>>>> expression. With this, for example:
>>>>
>>>>   BUILD_BUG_ON_ZERO(1 > 0)
>>>>
>>>> would now throw:
>>>>
>>>>   ./include/linux/compiler.h:197:62: error: static assertion failed: "1 > 0 is true"
>>>
>>> This is so much easier to read! Thanks for this. :)
>>>
>>> If no one else snags it, I can take this via the hardening tree for
>>> -next once -rc2 is released.
>>
>> I discussed about this with Andrew by DM.
>>
>> Andrew can pick it up but for the next-next release. That is to say,
>> wait for [1] to be merged in v6.16 and then take it to target the v6.17
>> merge windows.
>>
>> If you can take it in your hardening-next tree and have it merged in
>> v6.16, then this is convenient for me.
>>
>> Just make sure that you send it to Linus after Yury's bitmap-for-next
>> get merged: https://github.com/norov/linux/commits/bitmap-for-next/
> 
> Could this land via Yury's tree?

Hi Yury,

I have this patch:

https://lore.kernel.org/all/20250329-build_bug-v2-1-1c831e5ddf89@xxxxxxxxxx/

which depends on commit b88937277df ("drm/i915: Convert REG_GENMASK*()
to fixed-width GENMASK_U*()") in your bitmap-for-next tree.

I discussed this with Andrew (by DM) and Kees. Because of the
dependency, it would be convenient if this patch went through your tree.

What do you think?


Yours sincerely,
Vincent Mailhol