From: Benno Lossin <benno.lossin@proton.me>
To: Tamir Duberstein <tamird@gmail.com>
Cc: "Masahiro Yamada" <masahiroy@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nicolas@fjasle.eu>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Brendan Higgins" <brendan.higgins@linux.dev>,
"David Gow" <davidgow@google.com>, "Rae Moar" <rmoar@google.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Russ Weight" <russ.weight@linux.dev>,
"Rob Herring" <robh@kernel.org>,
"Saravana Kannan" <saravanak@google.com>,
"Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"FUJITA Tomonori" <fujita.tomonori@gmail.com>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org, linux-kselftest@vger.kernel.org,
kunit-dev@googlegroups.com, linux-pci@vger.kernel.org,
linux-block@vger.kernel.org, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org, netdev@vger.kernel.org
Subject: Re: [PATCH v7 7/7] rust: enable `clippy::ref_as_ptr` lint
Date: Wed, 26 Mar 2025 21:09:47 +0000 [thread overview]
Message-ID: <D8QI804Q3DAS.2BV4WSL81H52Z@proton.me> (raw)
In-Reply-To: <CAJ-ks9ntTxBM=c5nUZWGv3MoRt-LveBchn-c1Xy-DGap7fLVRA@mail.gmail.com>
On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote:
> On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote:
>> > 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].
>
> RIght. That guidance was written in 2016
> (https://github.com/rust-lang/rust/pull/34609) and doesn't present any
> rationale for `as` casts being preferred to transmute. I posted a
> comment in the most relevant issue I could find:
> https://github.com/rust-lang/rust/issues/34249#issuecomment-2755316610.
Not sure if that's the correct issue, maybe we should post one on the
UCG (unsafe code guidelines). But before that we probably should ask on
zulip...
>> No idea about provenance still.
>
> Well that's not surprising, nobody was thinking about provenance in
> 2016. But I really don't think we should blindly follow the advice in
> this case. It doesn't make an iota of sense to me - does it make sense
> to you?
For ptr-to-int transmutes, I know that they will probably remove
provenance, hence I am a bit cautious about using them for ptr-to-ptr or
ref-to-ref.
>> [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.
>
> It's not relevant because we're no longer talking about transmuting
> pointer to pointer. The two options are:
> 1. transmute reference to reference.
> 2. coerce reference to pointer, `as` cast pointer to pointer (triggers
> `ptr_as_ptr`), reborrow pointer to reference.
>
> If anyone can help me understand why (2) is better than (1), I'd
> certainly appreciate it.
I am very confident that (2) is correct. With (1) I'm not sure (see
above), so that's why I mentioned it.
---
Cheers,
Benno
next prev parent reply other threads:[~2025-03-26 21:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 20:07 [PATCH v7 0/7] rust: reduce `as` casts, enable related lints Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 1/7] rust: retain pointer mut-ness in `container_of!` Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 2/7] rust: enable `clippy::ptr_as_ptr` lint Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 3/7] rust: enable `clippy::ptr_cast_constness` lint Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 4/7] rust: enable `clippy::as_ptr_cast_mut` lint Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 5/7] rust: enable `clippy::as_underscore` lint Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 6/7] rust: enable `clippy::cast_lossless` lint Tamir Duberstein
2025-03-25 20:07 ` [PATCH v7 7/7] rust: enable `clippy::ref_as_ptr` lint Tamir Duberstein
2025-03-25 22:11 ` Benno Lossin
2025-03-25 22:33 ` Tamir Duberstein
2025-03-25 22:40 ` Benno Lossin
2025-03-25 23:54 ` Tamir Duberstein
2025-03-26 10:30 ` Benno Lossin
2025-03-26 10:35 ` Tamir Duberstein
2025-03-26 16:43 ` Benno Lossin
2025-03-26 16:57 ` Tamir Duberstein
2025-03-26 17:36 ` Benno Lossin
2025-03-26 19:06 ` Tamir Duberstein
2025-03-26 20:47 ` Tamir Duberstein
2025-03-26 21:09 ` Benno Lossin [this message]
2025-03-26 22:09 ` Tamir Duberstein
2025-03-26 22:15 ` Benno Lossin
2025-03-27 14:15 ` Tamir Duberstein
2025-03-27 19:44 ` Tamir Duberstein
2025-03-27 22:17 ` Benno Lossin
2025-03-27 0:22 ` kernel test robot
2025-03-25 20:22 ` [PATCH v7 0/7] rust: reduce `as` casts, enable related lints Miguel Ojeda
2025-03-25 23:31 ` Tamir Duberstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D8QI804Q3DAS.2BV4WSL81H52Z@proton.me \
--to=benno.lossin@proton.me \
--cc=a.hindborg@kernel.org \
--cc=abdiel.janulgue@gmail.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brendan.higgins@linux.dev \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=davidgow@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mripard@kernel.org \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas@fjasle.eu \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rmoar@google.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=russ.weight@linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=saravanak@google.com \
--cc=simona@ffwll.ch \
--cc=tamird@gmail.com \
--cc=tmgross@umich.edu \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.