Re: [PATCH v7 7/7] rust: enable `clippy::ref_as_ptr` lint

[Benno Lossin <benno.lossin@proton.me>]

On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote:
> On Wed, Mar 26, 2025 at 12:43 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> On Wed Mar 26, 2025 at 11:35 AM CET, Tamir Duberstein wrote:
>> > On Wed, Mar 26, 2025 at 6:31 AM Benno Lossin <benno.lossin@proton.me> wrote:
>> >> On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote:
>> >> > On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> >> >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote:
>> >> >> > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> >> >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote:
>> >> >> >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
>> >> >> >> > index 40034f77fc2f..6233af50bab7 100644
>> >> >> >> > --- a/rust/kernel/str.rs
>> >> >> >> > +++ b/rust/kernel/str.rs
>> >> >> >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool {
>> >> >> >> >      #[inline]
>> >> >> >> >      pub const fn from_bytes(bytes: &[u8]) -> &Self {
>> >> >> >> >          // SAFETY: `BStr` is transparent to `[u8]`.
>> >> >> >> > -        unsafe { &*(bytes as *const [u8] as *const BStr) }
>> >> >> >> > +        unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) }
>> >> >> >>
>> >> >> >> Hmm I'm not sure about using `transmute` here. Yes the types are
>> >> >> >> transparent, but I don't think that we should use it here.
>> >> >> >
>> >> >> > What's your suggestion? I initially tried
>> >> >> >
>> >> >> > let bytes: *const [u8] = bytes;
>> >> >> > unsafe { &*bytes.cast() }
>> >> >> >
>> >> >> > but that doesn't compile because of the implicit Sized bound on pointer::cast.
>> >> >>
>> >> >> This is AFAIK one of the only places where we cannot get rid of the `as`
>> >> >> cast. So:
>> >> >>
>> >> >>     let bytes: *const [u8] = bytes;
>> >> >>     // CAST: `BStr` transparently wraps `[u8]`.
>> >> >>     let bytes = bytes as *const BStr;
>> >> >>     // SAFETY: `bytes` is derived from a reference.
>> >> >>     unsafe { &*bytes }
>> >> >>
>> >> >> IMO a `transmute` is worse than an `as` cast :)
>> >> >
>> >> > Hmm, looking at this again we can just transmute ref-to-ref and avoid
>> >> > pointers entirely. We're already doing that in
>> >> > `CStr::from_bytes_with_nul_unchecked`
>> >> >
>> >> > Why is transmute worse than an `as` cast?
>> >>
>> >> It's right in the docs: "`transmute` should be the absolute last
>> >> resort." [1]. IIRC, Gary was a bit more lenient in its use, but I think
>> >> we should avoid it as much as possible such that people copying code or
>> >> taking inspiration also don't use it.
>> >>
>> >> So for both cases I'd prefer an `as` cast.
>> >>
>> >> [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html
>> >
>> > I don't follow the logic. The trouble with `as` casts is that they are
>> > very lenient in what they allow, and to do these conversions with `as`
>> > casts requires ref -> pointer -> pointer -> pointer deref versus a
>> > single transmute. The safety comment perfectly describes why it's OK
>> > to do: the types are transparent. So why is `as` casting pointers
>> > better? It's just as unchecked as transmuting, and worse, it requires
>> > a raw pointer dereference.
>>
>> Note that you're not transmuting `[u8]` to `BStr`, but `*const [u8]` to
>> `*const BStr`. Those pointers have provenance and I'm not sure if
>> transmuting them preserves it.
>
> In the current code you're looking at, yes. But in the code I have
> locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I
> said "Hmm, looking at this again we can just transmute ref-to-ref and
> avoid pointers entirely. We're already doing that in
> `CStr::from_bytes_with_nul_unchecked`".

`CStr::from_bytes_with_nul_unchecked` does the transmute with
references. That is a usage that the docs of `transmute` explicitly
recommend to change to an `as` cast [1].

No idea about provenance still.

[1]: https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives

>> I tried to find some existing issues about the topic and found that
>> there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue
>> asking for a better justification [1] and it seems like nobody provided
>> one there. Maybe we should ask the opsem team what happens to provenance
>> when transmuting?
>
> Yeah, we should do this - but again: not relevant in this discussion.

I think it's pretty relevant.

---
Cheers,
Benno