From: "Danilo Krummrich" <dakr@kernel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>
Cc: "Ke Sun" <sunke@kylinos.cn>, "Gary Guo" <gary@garyguo.net>,
"Benno Lossin" <lossin@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Tamir Duberstein" <tamird@gmail.com>,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] rust: fmt: reject {:p} format specifier for raw pointers
Date: Tue, 23 Dec 2025 12:27:45 +0100 [thread overview]
Message-ID: <DF5K6LPI70IW.VMT18WZTDLCR@kernel.org> (raw)
In-Reply-To: <CANiq72nZp-ULXMV9yG_PP=gkr0HUPTcE6ZRQhtgRp5Zk5SR6sA@mail.gmail.com>
On Tue Dec 23, 2025 at 7:41 AM CET, Miguel Ojeda wrote:
> Regarding the patch itself, ideally what we probably want is to do
> something similar to the C side, i.e. by default hash the pointers
> like C does, and then have an explicit way to request the real address
> when really needed.
Indeed, but I think the latter is even more important:
In C %p is commonly used for debugging when the actual address does not matter,
but a unique object needs to be identified (in quite a lot of cases to hunt down
memory bugs).
In Rust we should have quite fewer memory bugs to begin with (there may still be
ones in unsafe code, e.g. in abstractions) and we have built-in language
capabilities to easily derive debug prints for objects, which are more useful
then just a semi-unique identifier in a lot of cases.
So, what we are (mostly) left with I think are cases where we do want to print
the actual address temporarily for debug purposes, e.g. when interacting with
hardware (DMA memory, shared memory, etc.).
prev parent reply other threads:[~2025-12-23 11:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 3:30 [PATCH] rust: fmt: reject {:p} format specifier for raw pointers Ke Sun
2025-12-23 6:41 ` Miguel Ojeda
2025-12-23 8:03 ` Benno Lossin
2025-12-23 9:12 ` Ke Sun
2025-12-23 15:48 ` Timur Tabi
2025-12-23 11:27 ` Danilo Krummrich [this message]
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=DF5K6LPI70IW.VMT18WZTDLCR@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=lossin@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sunke@kylinos.cn \
--cc=tamird@gmail.com \
--cc=tmgross@umich.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox