linux-kernel - Re: [PATCH] rust: num: bounded: add safety comment for Bounded::_

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CANiq72=MfmAKfV7GGwkyNVZfmtcxdvCroUCwC3D4Y0dN_f70CQ@mail.gmail.com>
Date: Mon, 1 Dec 2025 13:44:24 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Hsiu Che Yu <yu.whisper.personal@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Yury Norov <yury.norov@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: num: bounded: add safety comment for Bounded::__new

On Mon, Dec 1, 2025 at 7:26 AM Hsiu Che Yu
<yu.whisper.personal@...il.com> wrote:
>
> Reported-by: Miguel Ojeda <ojeda@...nel.org>
> Closes: https://github.com/Rust-for-Linux/linux/issues/1211

So typically we have "fixes" or "improvements". The former ones
typically have Reported-by and Closes (and others like Fixes), while
improvements don't (and instead Suggested-by would be used in this
case).

I created the issue in this way to have you think about whether it
should be `unsafe fn` or not, and depending on the solution, the
eventual patch would be considered a fix (i.e. making it `unsafe fn`,
since it would not be intentional) or an improvement (i.e. documenting
why it is not unsafe, since it would have been intentionally safe).

Here you considered the solution to be that it should not be unsafe,
in which case it wouldn't be a fix and thus those tags wouldn't be
used.

The solution to the puzzle is now revealed, and indeed it should be
`unsafe fn` (even if it is private), so it is indeed a fix (but not
this fix, of course :).

[ In particular, functions having unsafe code inside of them is
orthogonal to them being unsafe functions or not, e.g. you may have
also safe functions with `unsafe` blocks inside. ]

For v2, you should consider what documentation you should add to make
it `unsafe fn` (please build with `CLIPPY=1` to check) and what others
changes would be needed.

Thanks for the patch!

Cheers,
Miguel