netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vsprintf: Remove SPECIAL from pointer types
Date: Sun, 06 Jul 2014 07:32:40 -0700	[thread overview]
Message-ID: <1404657160.27043.29.camel@joe-AO725> (raw)
In-Reply-To: <alpine.LFD.2.11.1407061222270.15455@eddie.linux-mips.org>

On Sun, 2014-07-06 at 12:44 +0100, Maciej W. Rozycki wrote:
> On Sat, 5 Jul 2014, Joe Perches wrote:
> 
> > Because gcc issues a complaint about any pointer format with %#p,
> > remove the use of SPECIAL to prefix 0x to various pointer types.
[]
>  Conceptually good, thanks for your effort, but you still need to clear 
> SPECIAL in `pointer' and maybe elsewhere, as that'll have been set for the 
> case concerned in `format_decode' by this code:
> 
> 		case '#': spec->flags |= SPECIAL; break;
> 
> (that doesn't check what follows) and then respected once `number' is 
> reached.  E.g.:
> 
> char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> 	      struct printf_spec spec)
> {
> 	int default_width = 2 * sizeof(void *);
> 
> 	spec.flags &= ~SPECIAL;
> 
> or suchlike.  Sorry to have been unclear about it.

I think you're not right here.
The patch shouldn't remove the capability to prefix.

But neither am I right with the commit log actually.
It should say something like "remove the default extra
width for the 0x prefix from %#p".

Actually, I'm not sure that removing "SPECIAL adds
the pointer prefix length" to width is that good.

I think it doesn't matter much.

I do like removing the prefix it from %pa though.

linux's printf like capability is not exactly like
gcc's.  It doesn't have to be.  linux's implementation
already does not prefix 0x to pointers when gcc does.
gcc uses '(nil)', linux '(null)', etc.

And linux's variant does a bunch of extended outputs
for %p<foo> variants where it overrides any size and
prefixing specified.

The only difference introduced by the proposed patch
here is that a generic pointer type will now have a
variable output width if %#p is used depending on the
high two bytes of the pointer value if a size is not
specified.

fyi: gcc will output a prefix 0x with %#p just as it
     does for %p.

The major difference is that linux uses a default of
sizeof(void *) * 2 for the width and zero fills without
prefix, gcc defaults to the minimum # of chars required
and prefixes.

cheers, Joe

  reply	other threads:[~2014-07-06 14:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-29  2:10 [PATCH v2] declance: Fix 64-bit compilation warnings Maciej W. Rozycki
2014-07-03  1:28 ` David Miller
2014-07-03  2:29   ` Maciej W. Rozycki
2014-07-03  2:34     ` Maciej W. Rozycki
2014-07-03  3:05       ` Joe Perches
2014-07-03  4:51         ` Maciej W. Rozycki
2014-07-03  5:16           ` Joe Perches
2014-07-03  6:01             ` Maciej W. Rozycki
2014-07-03  6:25               ` Joe Perches
2014-07-03 16:57                 ` Grant Likely
2014-07-05 14:56                 ` Maciej W. Rozycki
2014-07-05 16:07                   ` Joe Perches
2014-07-05 17:39                     ` Maciej W. Rozycki
2014-07-05 18:08                       ` Joe Perches
2014-07-05 18:20                         ` Maciej W. Rozycki
2014-07-05 18:31                           ` Joe Perches
2014-07-05 20:25                             ` Maciej W. Rozycki
2014-07-05 20:45                               ` [PATCH] vsprintf: Remove SPECIAL from pointer types Joe Perches
2014-07-06 11:44                                 ` Maciej W. Rozycki
2014-07-06 14:32                                   ` Joe Perches [this message]
2014-07-07  8:26                                 ` David Laight
2014-07-07 13:26                                   ` Joe Perches
2014-07-07 12:01                             ` [PATCH v2] declance: Fix 64-bit compilation warnings Grant Likely
2014-07-07 12:18                               ` Maciej W. Rozycki
2014-07-07 13:40                               ` Joe Perches

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=1404657160.27043.29.camel@joe-AO725 \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=netdev@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;
as well as URLs for NNTP newsgroup(s).