[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180205100305.GO29988@eros>
Date: Mon, 5 Feb 2018 21:03:05 +1100
From: "Tobin C. Harding" <me@...in.cc>
To: Petr Mladek <pmladek@...e.com>
Cc: Adam Borowski <kilobyte@...band.pl>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Joe Perches <joe@...ches.com>,
Kees Cook <keescook@...omium.org>,
"Roberts, William C" <william.c.roberts@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Laight <David.Laight@...LAB.COM>,
Randy Dunlap <rdunlap@...radead.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] vsprintf: avoid misleading "(null)" for %px
On Mon, Feb 05, 2018 at 10:44:38AM +0100, Petr Mladek 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@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?
>
> > Signed-off-by: Adam Borowski <kilobyte@...band.pl>
> > ---
> > lib/vsprintf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 77ee6ced11b1..d7a708f82559 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1849,7 +1849,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> > {
> > const int default_width = 2 * sizeof(void *);
> >
> > - if (!ptr && *fmt != 'K') {
> > + if (!ptr && *fmt != 'K' && *fmt != 'x') {
I don't know if it matters but with this it won't be immediately
apparent that a null pointer was printed (since zero could hash to
anything).
thanks,
Tobin.
Powered by blists - more mailing lists