linux-kernel - Re: [PATCH 6/9] CodingStyle: recommend static_assert/_Static

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251227194557.29d2afc5@pumpkin>
Date: Sat, 27 Dec 2025 19:45:57 +0000
From: David Laight <david.laight.linux@...il.com>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: corbet@....net, workflows@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/9] CodingStyle: recommend static_assert/_Static_assert

On Sat, 27 Dec 2025 17:51:49 +0300
Alexey Dobriyan <adobriyan@...il.com> wrote:

> On Tue, May 13, 2025 at 08:40:31PM +0100, David Laight wrote:
> > On Fri,  9 May 2025 23:34:27 +0300
> > Alexey Dobriyan <adobriyan@...il.com> wrote:
> >   
> > > Linux's BUG_ON is done backwards (condition is inverted).
> > > But it is a long story.
> > > 
> > > However C11/C23 allow to partially transition to what all normal
> > > programmers are used to, namely assert().
> > > 
> > > Deprecate BUILD_BUG_ON, recommend static_assert/_Static_assert.
> > > And then some day BUG_ON will be flipped as well.  
> > 
> > _Static_assert() is broken by design and only usable for trival tests.  
> 
> It is not broken by design. I was going to recommend it
> for "static_assert(sizeof(struct S) == ...)" type of things. For ABI types and
> similar stuff.

As I said, it can only be used for trivial tests.
Checking the sizes on structures is one of them.

You can't put one inside a compile-time conditional and the tested value
has to be an 'integer constant expression' not just a 'compile time constant'.
In particular that means you can't use it to check constant parameters to
inline functions or variables defined within statements blocks.

When I was rewriting min() there was an outer builtin_choose_expr(),
_Static_assert() within the 'unselected' expression would trip.
That really isn't what you want.

So there are many places where BUILD_BUG_ON() can be used but
_Static_assert() cannot be used.
BUILD_BUG_ON() cannot be deprecated until there is a working replacement.
That won't happen until the C language group actually understand how the
language is actually used :-)

The _Pragma(warning/error...) are just as useless.
They can only report things detected by pre-processor conditionals,
not checks that rely on the optimiser to have deleted unreachable code.

> 
> BTW BUILD_BUG_ON is broken by design too, there are places with fake functions
> for a block so that they can put statement in.

It works 'as designed' within the constraints of the language.
The error message required a log of 'lateral thought'.
Some of the 'fake functions' may well be replaceable with something
based on _Static_assert() - but that is only a small number.

> 
> > clang also output the entire expansion of the conditional (even when
> > a message is specified) which can lead to very very very very long lines.  
> 
> Oh, that's very unfortunate.
> 
> > It isn't at all suitable for many of the checks in the kernel.  
> 
> STATIC_ASSERT could be arranged.
> 
> > Look at the signedness test in min() as an example.  
> 
> The very fact you all made giant mess trying to imitate min<T, U>()
> should not block progress of using standard (and better!) stuff.

There are other 'sanity' checks like those in FIELD_PREP().
Without assigning the parameters to local variables the expansion
of FIELD_PREP(GENMASK(8, 5) val) comes to around 18KB.
And that is a typical use - not the triple-nests min() that came
out as multi-megabyte and broke compilation.

	David