Re: [PATCH] vsprintf: avoid misleading "(null)" for %px

[Tobin C. Harding]

On Tue, Feb 06, 2018 at 05:57:17AM +1100, Kees Cook wrote:
> On Mon, Feb 5, 2018 at 8:44 PM, Petr Mladek <pmladek@xxxxxxxx> wrote:
> > Hi,
> >
> > I add people who actively commented on adding %px modifier,
> > see the thread starting at
> > https://lkml.kernel.org/r/1511921105-3647-5-git-send-email-me@xxxxxxxx
> >
> > Just for reference. It seems to be related to the commit 9f36e2c448007b54
> > ("printk: use %pK for /proc/kallsyms and /proc/modules").
> >
> >
> > On Sun 2018-02-04 18:45:21, Adam Borowski wrote:
> >> Like %pK already does, print "00000000" instead.
> >>
> >> This confused people -- the convention is that "(null)" means you tried to
> >> dereference a null pointer as opposed to printing the address.
> >
> > By other words, this avoids regressions when people convert
> > %x to %px. Do I get it right, please?
> 
> Nothing should be converting from %x to %px, it's %p to %px. %p print
> "(null)" for 0x0, so it would be surprising for a conversion from %p
> to %px to change that. (Though generally speaking "(null)" is never
> useful...)

Leaving aside what is converting to %px.  If we consider that using %px
is meant to convey to us that we _really_ want the address, in hex hence
the 'x', then it is not surprising that we will get "00000000"'s for a
null pointer, right?  Yes it is different to before but since we are
changing the specifier does this not imply that there may be some
change?

In what is now to be expected fashion for %p the discussion appears to
have split into two different things - what to do with %px and what to
do with %pK :)

thanks,
Tobin.