On Tue, Feb 6, 2018 at 7:15 AM, Tobin C. Harding <m...@tobin.cc> wrote: > On Tue, Feb 06, 2018 at 05:57:17AM +1100, Kees Cook wrote: >> On Mon, Feb 5, 2018 at 8:44 PM, Petr Mladek <pmla...@suse.com> 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...@tobin.cc >> > >> > 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?
I personally prefer 0000s, but if we're going to change this, we need to be aware of the difference. > 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 :) I say leave %pK alone. :) -Kees -- Kees Cook Pixel Security