Re: [PATCH] rust: fmt: reject {:p} format specifier for raw pointers

["Benno Lossin" <lossin@kernel.org>]

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.

Could that just be some kconfig option or do people want to do that
without recompiling? But yeah, as always with these things, we should
use the principle of "add those capabilities, which already are
available on the C side to Rust".

> For the real address case, we could require wrapping the pointer-like
> argument into another type, so that it is very explicit and opt-in
> (since having our own custom formatting is harder, though perhaps we
> should finally look into that -- Cc'ing Gary/Benno may have some ideas
> in this domain).

Well, we could have something like `PrintRealPointerAddress`. But if
someone would really want to print the address of a pointer without
using it, they could just do:

    let ptr: *mut T = ...;
    pr_info!("pointer value: {:x}", ptr.addr());

So unless we also have a lint on printing `<*mut T>::addr`, then I'd say
it's only useful for people that know of it and reviewers still need to
be on the lookout for people trying to print pointers. (but I guess this
is similar to the C side, where you can just cast to an size_t or
whatever is the correct thing, right? (or are there lints for that?))

> Otherwise, if we land something like this, how does one print a
> pointer when needed without having to manually replicate the
> formatting? `:?` perhaps? But that is almost as easy to make a mistake
> with as `:p`, so that should probably be included. It is actually what
> was done in https://github.com/rust-lang/rust-clippy/pull/14792, i.e.
> both are caught by the lint. Cc'ing Trevor who was involved in
> reviewing that one.
>
> Speaking about the lint: since it got implemented, assuming it works
> well, then we could just use the lint, which allows developers to at
> least opt-out when needed, e.g. debugging, until we get the hashing
> etc.

We'd still need something for the older compiler versions, or is it
enough to have the lint in the latest/only in some stable releases?

> Finally, when the macro shouldn't work, normally we just panic the
> macro, is the `compiler_error` meant for diagnostics?

Emitting a `compiler_error` normally is more ergonomic wrt. diagnostics,
since the erroneous code still gets emitted, which prevents other errors
from occurring. Here it probably isn't necessary, but an example where
it is important is `#[pin_data]`, if it panics, it also doesn't emit the
struct definitions, leading to undefined type errors everywhere the type
is used.

Cheers,
Benno