linux-kernel - Re: [PATCH 2/2] rust: add `const

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYgmENPRTdD4wCVF@yury>
Date: Sun, 8 Feb 2026 00:58:40 -0500
From: Yury Norov <ynorov@...dia.com>
To: Gary Guo <gary@...yguo.net>
Cc: Benno Lossin <lossin@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
	Boqun Feng <boqun@...nel.org>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	Yury Norov <yury.norov@...il.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nsc@...nel.org>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 2/2] rust: add `const_assert!` macro

On Fri, Feb 06, 2026 at 09:48:59PM +0000, Gary Guo wrote:
> On Fri Feb 6, 2026 at 9:30 PM GMT, Benno Lossin wrote:
> > On Fri Feb 6, 2026 at 6:12 PM CET, Gary Guo wrote:
> >> +/// Assertion during constant evaluation.
> >> +///
> >> +/// This is a more powerful version of `static_assert` that can refer to generics inside functions
> >> +/// or implementation blocks. However, it also have a limitation where it can only appear in places
> >> +/// where statements can appear; for example, you cannot use it as an item in the module.
> >> +///
> >> +/// [`static_assert!`] should be preferred where possible.

This is confusing. You begin with "const_assert!() is more powerful",
and finally recommend to use a less powerful option.

> >> +///
> >> +/// # Examples
> >> +///
> >> +/// When the condition refers to generic parameters [`static_assert!`] cannot be used.
> >> +/// Use `const_assert!` in this scenario.
> >> +/// ```
> >> +/// fn foo<const N: usize>() {
> >> +///     // `static_assert!(N > 1);` is not allowed
> >> +///     const_assert!(N > 1); // Compile-time check
> >> +///     build_assert!(N > 1); // Build-time check
> >
> > I think having "Build-time check" here is a bit confusing, how about we
> > change it to "Link-time check"? Since a "Compile-time check" also is
> > done at "Build-time"
> 
> This is the intentional phrasing that I used for `build_assert!` when I created
> it, for the reason that `build_assert!` ensure that it will fire, at latest,
> link time. However, if you actually use such methods with CTFE, it will error
> earlier. So it is "at latest link-time check", so I decided to just use
> "build-time".

I don't think this compiler implementation details should sneak into
the kernel. The compiler may get changed, or whatever else, and this
all will become just non-relevant.

So, can you once more explain when static_assert!() is preferable over
const_assert!() over build_assert!(); strictly from a users' perspective?

On the C side we've got similar statically_true() and const_true()
macros, but they seemingly have a different meaning:

  /*
   * Useful shorthand for "is this condition known at compile-time?"
   *
   * Note that the condition may involve non-constant values,
   * but the compiler may know enough about the details of the
   * values to determine that the condition is statically true.
   */
  #define statically_true(x) (__builtin_constant_p(x) && (x))

  /*
   * Similar to statically_true() but produces a constant expression
   *
   * To be used in conjunction with macros, such as BUILD_BUG_ON_ZERO(),
   * which require their input to be a constant expression and for which
   * statically_true() would otherwise fail.
   *
   * This is a trade-off: const_true() requires all its operands to be
   * compile time constants. Else, it would always returns false even on
   * the most trivial cases like:
   *
   *   true || non_const_var
   *
   * On the opposite, statically_true() is able to fold more complex
   * tautologies and will return true on expressions such as:
   *
   *   !(non_const_var * 8 % 4)
   *
   * For the general case, statically_true() is better.
   */
  #define const_true(x) __builtin_choose_expr(__is_constexpr(x), x, false)

Is it possible to maintain consistency with C on rust side? If not,
can you take those C comments as the reference for what level of
detalization is desired? Maybe pick different names then?

Thanks,
Yury