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

Message-ID: <CANiq72kkLe-to9hO9+Q6kk-xpfAUZTCEBug05USruPymE4GkeA@mail.gmail.com>
Date: Mon, 9 Feb 2026 12:44:19 +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 10:07 PM Yury Norov <ynorov@...dia.com> wrote:
>
> Can you please keep more context? It would be easier to refer to an
> example if I have it on hand.

The existing docs for `build_assert!` have a couple examples that may help:

  https://rust.docs.kernel.org/kernel/macro.build_assert.html

(Those are the kind of examples I would like to have in the module
level docs, I think they help a lot to quickly see for what each one
is used for, even if one may not know the exact Rust terminology
etc.).

> I agree with ""Build-time check" here is a bit confusing", and the
> following indeed looks like a compiler implementation discussion. So
> I concluded that the difference between build_assert and const_assert
> is not visible from programmer's POV. Please correct me if I'm wrong.

Gary has also nicely explained in detail the three Rust ones -- what I
was suggesting is to take something like that and put it in a single
explanation in the module docs, with the examples we have (or others).

In any case, to reply to this bit above: `build_assert!` allows way
more expressions than `const_assert!` does -- the ones you call
"runtime conditions". So it is very visible to the programmer.

(Not sure if I would call them "runtime conditions" though, i.e. that
sounds like a normal condition that gets checked at runtime. Hopefully
the optimizer also deleted as much code as it could...)

By the way, in C, `compiletime_assert` (if the compiler supports the
attribute, which GCC and Clang do nowadays) fails in the actual
compiler rather than the linker, so I guess it is a fair name, even if
post-optimizations. But the fallback still fails later, so in general
it isn't always at compilation time (and the docs use wording like
"break build"). I guess we could eventually rename the Rust one
`compiletime_assert` to match, especially if we get support in the
Rust compiler for something like the attribute (there are already more
`build_assert` calls than `compiletime_assert` ones in the tree,
funnily... :)

> I suggested const_true() over the original underscored _statically_true(),
> and this is an obvious improvement. If you think that 'constexpr_true()'
> would add to explainability, please submit a patch. I have a weakly
> negative opinion on that.

Thanks for that context. Hmm... In that case, given the current name
was meant as an improvement over the underscored one, rather than
other reason (i.e. perhaps I was missing something), then yeah, I
think I may submit the patch. It is not important obviously, but it
never hurts to try to align these things to reduce confusion, and it
is just a few callers unlike other macros...

Cheers,
Miguel