Re: [PATCH] rust: fmt: drop the "0x" prefix from {:p} to match %p

[Carlos Llamas <cmllamas@google.com>]

On Tue, Oct 06, 2026 at 11:09:09PM +0200, Gary Guo wrote:
> On Tue Oct 6, 2026 at 8:38 PM CEST, Carlos Llamas wrote:
> > Commit 643a7c306b8c ("rust: fmt: route {:p} through HashedPtr to prevent
> > address leaks") made {:p} go through the kernel's %p so that pointers
> > are hashed by default. However, it formats them with %#0*p, where the
> > '#' flag prepends a '0x' prefix that the plain %p does not produce in C.
> > Thus the same pointer is printed differently from C and from Rust:
> >
> >     C     %p      00000000e8efa736
> >     Rust  {:p}  0x00000000e8efa736
> >
> > The prefix is a leftover from 'core::fmt::Pointer', which always adds
> > one. However, doing so deviates from the %p format documented in
> > Documentation/core-api/printk-formats.rst and makes it harder to
> > correlate the same pointer across C and Rust messages.
> >
> > Format the pointer with '%0*p' instead and adjust the default field
> > width accordingly, so that {:p} produces exactly the same output as
> > plain %p which is zero-padded to the width of a pointer and without any
> > prefix, both for hashed pointers and for real addresses under
> > 'no_hash_pointers'. Update the KUnit test expectations to match.
> >
> > Note this patch focuses only on fixing the '{:p}' prefix to match %p.
> > The '#' flag remains ignored as before, so the '{:#p}' equivalent to
> > %#p should be sent as a follow up patch.
> >
> > Fixes: 643a7c306b8c ("rust: fmt: route {:p} through HashedPtr to prevent address leaks")
> 
> Rust libcore's `:p` also adds the 0x, so I don't consider this a fix.
> This will be an intentional behaviour divergence from Rust format specifier, so
> this fact need to be mentioned explicitly.

I see. I was afraid this was going to be the case. Then, I don't know if
:p in the kernel should follow %p or std:fmt. It diverges either way.
For context, I ran into this issue because log parsing broke in binder
when I started using :p due to the unexpected prefix.

I suppose one can always open code a %p equivalent as needed too but
perhaps matching the %p behavior make more sense? I dunno, wdyt?

--
Carlos Llamas