Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Shuah Khan <shuah@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 12/13] tools/nolibc: add __nolibc_static_assert()
Date: Wed, 3 Dec 2025 20:23:30 +0100	[thread overview]
Message-ID: <20251203192330.GA12995@1wt.eu> (raw)
In-Reply-To: <57a98a13-4d88-4d83-b9f4-77a0a665be8a@t-8ch.de>

On Wed, Dec 03, 2025 at 08:19:13PM +0100, Thomas Weißschuh wrote:
> On 2025-11-30 12:08:56+0100, Willy Tarreau wrote:
> > On Sat, Nov 22, 2025 at 05:59:18PM +0100, Thomas Weißschuh wrote:
> > > Add a wrapper for _Static_assert() to use within nolibc.
> > > While _Static_assert() itself was only standardized in C11,
> > > in GCC and clang dialects it is also available in older standards.
> > > 
> > > If it turns out that _Static_assert can't be used in some contexts,
> > > this wrapper can be adapted.
> > > 
> > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > > ---
> > >  tools/include/nolibc/compiler.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/tools/include/nolibc/compiler.h b/tools/include/nolibc/compiler.h
> > > index 87090bbc53e0..ef247e916552 100644
> > > --- a/tools/include/nolibc/compiler.h
> > > +++ b/tools/include/nolibc/compiler.h
> > > @@ -47,4 +47,6 @@
> > >  #  define __nolibc_fallthrough do { } while (0)
> > >  #endif /* __nolibc_has_attribute(fallthrough) */
> > >  
> > > +#define __nolibc_static_assert(_t) _Static_assert(_t, "")
> > 
> > I'm not super fan of raising the bar to adoption by introducing forced
> > C11-isms, especially when they're only used to perform extra safety
> > checks that likely remain fine after you've checked them once. What
> > about instead:
> > 
> > +#if __STDC_VERSION__ >= 201112L
> > +# define __nolibc_static_assert(_t) _Static_assert(_t, "")
> > +#endif
> > +# define __nolibc_static_assert(_t) do { } while (0)
> > +#else
> > 
> > Note that this won't work out of code blocks but we very likely don't
> > care. And if we'd care, we could always switch to __asm__("") which
> > works everywhere.
> >  
> > What do you think ?
> 
> That works. But it won't be evaluated when not building with C11.
> Which would not make it trigger when building nolibc-test.
> So I don't want to guard it behind __STDC_VERSION__. But so far I was
> not able to find a better, more dynamic guard. I'll look again.
> Non-standard _Static_assert() is supported since GCC 4.6 and clang 3.0.

Fine, then we can just have a compiler version check as well, even a rough
one, since we don't reallly care about static asserts for pretty old or
uncommon versions, but for the modern ones that are used by developers
and test systems.

I'd suggest going the easy route for now by checking for GCC major >= 5
or clang major >= 3 and be done with it.

Willy

  reply	other threads:[~2025-12-03 19:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-22 16:59 [PATCH v2 00/13] tools/nolibc: always use 64-bit time-related types Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 01/13] tools/nolibc/poll: use kernel types for system call invocations Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 02/13] tools/nolibc/poll: drop __NR_poll fallback Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 03/13] tools/nolibc/select: drop non-pselect based implementations Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 04/13] tools/nolibc/time: drop invocation of gettimeofday system call Thomas Weißschuh
2025-11-30 10:42   ` Willy Tarreau
2025-11-22 16:59 ` [PATCH v2 05/13] tools/nolibc: prefer explicit 64-bit time-related system calls Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 06/13] tools/nolibc/gettimeofday: avoid libgcc 64-bit divisions Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 07/13] tools/nolibc/select: avoid libgcc 64-bit multiplications Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 08/13] tools/nolibc: use custom structs timespec and timeval Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 09/13] tools/nolibc: always use 64-bit time types Thomas Weißschuh
2025-11-30 10:58   ` Willy Tarreau
2025-12-01  7:45     ` Arnd Bergmann
2025-12-01 10:35       ` Willy Tarreau
2025-12-01 10:53         ` Arnd Bergmann
2025-11-22 16:59 ` [PATCH v2 10/13] selftests/nolibc: test compatibility of nolibc and kernel " Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 11/13] tools/nolibc: remove time conversions Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 12/13] tools/nolibc: add __nolibc_static_assert() Thomas Weißschuh
2025-11-30 11:08   ` Willy Tarreau
2025-12-03 19:19     ` Thomas Weißschuh
2025-12-03 19:23       ` Willy Tarreau [this message]
2025-12-03 20:08         ` Thomas Weißschuh
2025-11-22 16:59 ` [PATCH v2 13/13] selftests/nolibc: add static assertions around time types handling Thomas Weißschuh
2025-11-30 11:10 ` [PATCH v2 00/13] tools/nolibc: always use 64-bit time-related types Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251203192330.GA12995@1wt.eu \
    --to=w@1wt.eu \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox