From: Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Joe Perches <joe@perches.com>,
linux-wireless@vger.kernel.org, bzhao@marvell.com
Subject: Re: [PATCH] mwifiex: Using %*phD instead of print_hex_dump_bytes
Date: Fri, 5 Oct 2012 13:27:52 +0300 [thread overview]
Message-ID: <20121005102750.GG12229@aemeltch-MOBL1> (raw)
In-Reply-To: <1349432305.10584.29.camel@smile>
Hi Andy,
On Fri, Oct 05, 2012 at 01:18:25PM +0300, Andy Shevchenko wrote:
> On Fri, 2012-10-05 at 13:11 +0300, Andrei Emeltchenko wrote:
> > On Fri, Oct 05, 2012 at 09:53:16AM +0300, Andy Shevchenko wrote:
> > > On Thu, 2012-10-04 at 09:32 -0700, Joe Perches wrote:
>
> > > > When the number of bytes is fixed, it might be nicer
> > > > to use a format like "%<num>ph" so that the function
> > > > argument stack doesn't have the width pushed but it's
> > > > fixed in the format.
> > > >
> > > > This case would definitely not work well though as it's
> > > > a #define rather than a simple number and I think
> > > > using "%" stringize(some_define) "ph" is not nice.
> > > >
> > > > Maybe this case argues more for always using "%*ph".
> > > > At least that's easily greppable.
>
>
> > > I checked briefly the code and found that the constant is heavily used
> > > as a definition for the length of static byte arrays. So, in that case
> > > probably better to use %*ph, but apply sizeof(cool_var) instead of
> > > putting constant there.
> >
> > I did not touch logic that print buffer, the buffer might have lots of
> > data (even significantly more then you may want to print to logs) so
> > using sizeof is not the best idea in these cases.
> Then you probably need to decide how much you would like to print
> exactly and put that constant directly to the %*ph (instead of
> asterisk), like %5ph. Otherwise it's unclear what DBG_CMD_NUM stands
I do not like much magic numbers. Defines are the same as those magic
numbers. You always see them with one jump and usually you do reuse them
anyway.
Best regards
Andrei Emeltchenko
next prev parent reply other threads:[~2012-10-05 10:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-04 9:16 [PATCH] mwifiex: Using %*phD instead of print_hex_dump_bytes Andrei Emeltchenko
2012-10-04 16:32 ` Joe Perches
2012-10-05 6:53 ` Andy Shevchenko
2012-10-05 7:00 ` Andy Shevchenko
2012-10-05 10:07 ` Andrei Emeltchenko
2012-10-05 10:19 ` Andy Shevchenko
2012-10-05 12:58 ` Andrei Emeltchenko
2012-10-05 19:43 ` Bing Zhao
2012-10-05 10:11 ` Andrei Emeltchenko
2012-10-05 10:18 ` Andy Shevchenko
2012-10-05 10:27 ` Andrei Emeltchenko [this message]
2012-10-05 19:35 ` Bing Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121005102750.GG12229@aemeltch-MOBL1 \
--to=andrei.emeltchenko.news@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bzhao@marvell.com \
--cc=joe@perches.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox