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

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

[Vincent Mailhol]

__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"
    197 | define __BUILD_BUG_ON_ZERO_MSG(e, msg) ((int)sizeof(struct {_Static_assert(!(e), msg);}))
        |                                                             ^~~~~~~~~~~~~~

Finally, __BUILD_BUG_ON_ZERO_MSG() is already guarded by an:

  #ifdef __CHECKER__

So no need any more for that guard clause for BUILD_BUG_ON_ZERO().
Remove it.

[1] commit d7a516c6eeae ("compiler.h: Fix undefined BUILD_BUG_ON_ZERO()")
Link: https://git.kernel.org/torvalds/c/d7a516c6eeae

Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
---
** Prerequisite **

This patch depends on:

  commit b88937277df ("drm/i915: Convert REG_GENMASK*() to fixed-width GENMASK_U*()")
  Link: https://git.kernel.org/next/linux-next/c/b88937277df

Changelog:

  v1 -> v2:

    - The patch caused an issue because of a conflict in drm/i915:

      Link: https://lore.kernel.org/all/202412080849.sPp82jSi-lkp@intel.com/

      Above conflict is indirectly resolved by commit b88937277df
      (c.f. above prerequisite).

      Now that the conflict is resolved, resend the patch.

    - Remove the intermediary __BUILD_BUG_ON_ZERO() macro, instead,
      make __BUILD_BUG_ON_ZERO_MSG() variadic.

  Link to v1: https://lore.kernel.org/all/20241205151316.1480255-2-mailhol.vincent@wanadoo.fr/
---
 include/linux/build_bug.h | 10 +++++-----
 include/linux/compiler.h  |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index 3aa3640f8c181f6a54bacffbc43260b57481e67f..2cfbb4c65c784ad82edd1e45c1b4f4c23e78b009 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -4,17 +4,17 @@
 
 #include <linux/compiler.h>
 
-#ifdef __CHECKER__
-#define BUILD_BUG_ON_ZERO(e) (0)
-#else /* __CHECKER__ */
 /*
  * Force a compilation error if condition is true, but also produce a
  * result (of value 0 and type int), so the expression can be used
  * e.g. in a structure initializer (or where-ever else comma expressions
  * aren't permitted).
+ *
+ * Take an error message as an optional second argument. If omitted,
+ * default to the stringification of the tested expression.
  */
-#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
-#endif /* __CHECKER__ */
+#define BUILD_BUG_ON_ZERO(e, ...) \
+	__BUILD_BUG_ON_ZERO_MSG(e, ##__VA_ARGS__, #e " is true")
 
 /* Force a compilation error if a constant expression is not a power of 2 */
 #define __BUILD_BUG_ON_NOT_POWER_OF_2(n)	\
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 9fc30b6b80c9ef8e53a89f53c16ebbe84e40eedb..48793a7822daad99b27324848d585e3cd9893e71 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -192,9 +192,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 })
 
 #ifdef __CHECKER__
-#define __BUILD_BUG_ON_ZERO_MSG(e, msg) (0)
+#define __BUILD_BUG_ON_ZERO_MSG(e, msg, ...) (0)
 #else /* __CHECKER__ */
-#define __BUILD_BUG_ON_ZERO_MSG(e, msg) ((int)sizeof(struct {_Static_assert(!(e), msg);}))
+#define __BUILD_BUG_ON_ZERO_MSG(e, msg, ...) ((int)sizeof(struct {_Static_assert(!(e), msg);}))
 #endif /* __CHECKER__ */
 
 /* &a[0] degrades to a pointer: a different type from an array */

---
base-commit: de305063001d5624138a452bdb2d56e68dc2301c
change-id: 20250327-build_bug-a55c1812ce51

Best regards,
-- 
Vincent Mailhol <mailhol.vincent@wanadoo.fr>

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

[Kees Cook]

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.

-- 
Kees Cook

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

[Vincent Mailhol]

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/

Usually, bitmap changes are merged at the very beginning of the merge
window so that should be OK.


[1] commit b88937277df ("drm/i915: Convert REG_GENMASK*() to fixed-width
GENMASK_U*()")
Link: https://git.kernel.org/next/linux-next/c/b88937277df

Yours sincerely,
Vincent Mailhol

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

[Kees Cook]

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?

-- 
Kees Cook

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@wanadoo.fr/

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

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

[Yury Norov]

On Wed, Apr 09, 2025 at 09:26:41PM +0900, Vincent Mailhol wrote:
> +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@wanadoo.fr/
> 
> 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?

Sure, I can merge it. Please everyone send your tags before the end of
week.

Thanks,
Yury

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

[Kees Cook]

On Wed, Apr 09, 2025 at 10:17:49AM -0400, Yury Norov wrote:
> On Wed, Apr 09, 2025 at 09:26:41PM +0900, Vincent Mailhol wrote:
> > +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@wanadoo.fr/
> > 
> > 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?
> 
> Sure, I can merge it. Please everyone send your tags before the end of
> week.

Thanks!

Reviewed-by: Kees Cook <kees@kernel.org>

-- 
Kees Cook

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

[Yury Norov]

> > > Hi Yury,
> > > 
> > > I have this patch:
> > > 
> > > https://lore.kernel.org/all/20250329-build_bug-v2-1-1c831e5ddf89@wanadoo.fr/
> > > 
> > > 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?
> > 
> > Sure, I can merge it. Please everyone send your tags before the end of
> > week.
> 
> Thanks!
> 
> Reviewed-by: Kees Cook <kees@kernel.org>

Applied, thanks!

Thanks,
Yury