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: <CANiq72k4D0ZPDzBCHY7xq=qOmERHk3e7P8CcKtVHjjjOQhJ+2w@mail.gmail.com>
Date: Sun, 8 Feb 2026 11:35:51 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Yury Norov <ynorov@...dia.com>
Cc: Gary Guo <gary@...yguo.net>, 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 Sun, Feb 8, 2026 at 6:58 AM Yury Norov <ynorov@...dia.com> wrote:
>
> This is confusing. You begin with "const_assert!() is more powerful",
> and finally recommend to use a less powerful option.

The goal is that users use the least powerful one that applies, not
the other way around, because the least powerful ones fail earlier and
are generally more robust.

I think the first example is intended to show the different ones, but
I think the wording can be improved -- the one in the existing
`build_assert!` docs is a bit clearer.

Gary: perhaps we could factor out the explanation/examples to the
module-level docs, and then link to it from all the three asserts.

> 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.

How do they sneak into the kernel? Gary is explaining why it is not
called "link time", precisely because that would expose more details,
not less.

Regardless, that "link-time" vs. "build-time" discussion is
independent of this patch, because those docs already exist in the
tree.

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

> 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?

Please explain what inconsistency you are seeing here.

Also, please note that two of the three names have been for years in
the kernel tree, and that standard C also uses `static_assert` as a
name. `const_assert` fits the pattern and it literally expands to what
it says.

Moreover, `const` in C is not the same as `const` in Rust. `constexpr`
in C is closer to `const` in Rust.

By the way, I am not sure why you suggested `const_true` for the name
of that C macro -- I think it should be `constexpr_true` instead,
which is closer to what it does, and it fits the pattern on the C side
better, too. So that would be more consistent.

Cheers,
Miguel