From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752877AbbL1WVB (ORCPT <rfc822;w@1wt.eu>);
	Mon, 28 Dec 2015 17:21:01 -0500
Received: from mail-wm0-f46.google.com ([74.125.82.46]:33543 "EHLO
	mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752566AbbL1WU4 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 28 Dec 2015 17:20:56 -0500
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Joe Perches <joe@perches.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] lib/vsprintf: refactor duplicate code to xnumber()
Organization: D03
References: <1451326703-122826-1-git-send-email-andriy.shevchenko@linux.intel.com>
	<1451327112.3219.14.camel@perches.com>
	<87h9j245ed.fsf@rasmusvillemoes.dk>
X-Hashcash: 1:20:151228:andriy.shevchenko@linux.intel.com::zUvWcjY234f1EeUt:0000000000000000000000000000054N
X-Hashcash: 1:20:151228:akpm@linux-foundation.org::4e3WP1h+M4Z9T6T7:0000000000000000000000000000000000000i6M
X-Hashcash: 1:20:151228:linux-kernel@vger.kernel.org::nGAk8siFsP75yJRa:0000000000000000000000000000000006Kq+
X-Hashcash: 1:20:151228:joe@perches.com::23oaA8UMk8CstCBa:009dwN
Date: Mon, 28 Dec 2015 23:20:54 +0100
In-Reply-To: <87h9j245ed.fsf@rasmusvillemoes.dk> (Rasmus Villemoes's message
	of "Mon, 28 Dec 2015 22:42:02 +0100")
Message-ID: <87d1tq43ll.fsf@rasmusvillemoes.dk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Dec 28 2015, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:

>
> Is there any aspect of the passed-through printf_spec which isn't
> overridden in xnumber? The users are/will be various %p extensions,
> which probably means that no-one passes a non-default precision (gcc
> complains about %.*p), and the remaining possible flags (PLUS, LEFT,
> SPACE) are useless and/or impossible to pass to %p

Actually, LEFT can be passed to %p (or get set by passing a negative
field width via %*p), which would be actively harmful: When LEFT is set,
number() explicitly removes the ZEROPAD flag, so we'd get "0xabcdef  "
instead of "0x00abcdef".