[lkml]   [2017]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH V8 1/2] printk: remove tabular output for NULL pointer
On Thu, 2017-10-26 at 17:27 +1100, Tobin C. Harding wrote:
> Hi Joe,
> thanks for your review.
> On Wed, Oct 25, 2017 at 09:57:23PM -0700, Joe Perches wrote:
> > On Thu, 2017-10-26 at 13:53 +1100, Tobin C. Harding wrote:
> > > Currently pointer() checks for a NULL pointer argument and then if so
> > > attempts to print "(null)" with _some_ standard width. This width cannot
> > > correctly be ascertained here because many of the printk specifiers
> > > print pointers of varying widths.
> >
> > I believe this is not a good change.
> > Only pointers without a <foo> extension call pointer()
> Sorry, I don't understand what you mean here. All the %p<foo> specifier code is
> handled by pointer()?

Sorry, I was imprecise/wrong.

None of the %p<foo> extensions except %pK and %p<invalid_foo>
actually use this bit of the pointer() call.

All of the other valid %p<foo> extension uses do not end up
at this block being executed so it's effectively only regular
pointers being output by number()

> > > Remove the attempt to print NULL pointers with a correct width.
> >
> > the correct width for a %p is the default width.
> It is the default width if we are printing addresses. Once we hash 64
> bit address to a 32 bit identifier then we don't have a default width.

Perhaps that 32 bit identifier should use leading 0's for
the default width.


Why hash 64 bits to 32?
Why shouldn't the hash width be 64 bits on 64 bit systems?

 \ /
  Last update: 2017-10-26 10:06    [W:0.070 / U:4.340 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site