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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <692d9994.050a0220.d1d07.6e65@mx.google.com>
Date: Mon, 1 Dec 2025 21:35:14 +0800
From: Hsiu Che Yu <yu.whisper.personal@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Hsiu Che Yu <yu.whisper.personal@...il.com>,
	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 01, 2025 at 01:44:24PM +0100, Miguel Ojeda wrote:
>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

I previously believed that a function should only be marked unsafe when 
it directly operates on unsafe code. I now understand that the decision 
should be based on the actual safety implications rather than just 
semantic considerations.

Thank you also for the clarification on the tags. I spent some time 
trying to understand them, and your explanation is very helpful.

I will address this in v2 by making it an `unsafe fn` and documenting
the safety requirements in the `# Safety` section.

Best regards,
Hsiu Che Yu