From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753558AbbKZVXw (ORCPT ); Thu, 26 Nov 2015 16:23:52 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:35385 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752640AbbKZVXs (ORCPT ); Thu, 26 Nov 2015 16:23:48 -0500 From: Rasmus Villemoes To: Andy Shevchenko Cc: Andrew Morton , "linux-kernel\@vger.kernel.org" Subject: Re: [PATCH 07/14] lib/vsprintf.c: slightly refactor vscnprintf() Organization: D03 References: <1448314171-25856-1-git-send-email-linux@rasmusvillemoes.dk> <1448314171-25856-8-git-send-email-linux@rasmusvillemoes.dk> X-Hashcash: 1:20:151126:akpm@linux-foundation.org::m1wJPYu12RaouxnT:0000000000000000000000000000000000000h92 X-Hashcash: 1:20:151126:andy.shevchenko@gmail.com::70mxXkFFHiGdh4lO:0000000000000000000000000000000000006LoK X-Hashcash: 1:20:151126:linux-kernel@vger.kernel.org::Pu4iH0Uhfq/3GSfL:0000000000000000000000000000000005l2N Date: Thu, 26 Nov 2015 22:23:45 +0100 In-Reply-To: (Andy Shevchenko's message of "Tue, 24 Nov 2015 00:39:16 +0200") Message-ID: <871tbce9pa.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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 23 2015, Andy Shevchenko wrote: > On Mon, Nov 23, 2015 at 11:29 PM, Rasmus Villemoes > wrote: >> If we're given a size of 0, the vsnprintf() won't have any side >> effects, and neither "i < size" or "size != 0" will trigger. So we >> might as well return 0 immediately. >> >> Signed-off-by: Rasmus Villemoes >> --- >> lib/vsprintf.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/lib/vsprintf.c b/lib/vsprintf.c >> index 8af5535fd738..e22a6189548f 100644 >> --- a/lib/vsprintf.c >> +++ b/lib/vsprintf.c >> @@ -2036,13 +2036,14 @@ int vscnprintf(char *buf, size_t size, const char *fmt, va_list args) >> { >> int i; >> >> + if (unlikely(!size)) >> + return 0; >> + > > Might it potentially shadow any issue when run vsnprintf(buf, 0, fmt, > args); with certain arguments? Only if we ever come up with a %p extension with side effects, but then people couldn't rely on them happening exactly once anyway (kasprintf would make them happen twice). printf-like calls are also often compiled out or disabled (dyndebug, ratelimit, ...) without it being obvious at the call site whether they'll run or not, so I think such a hypothetical %p extension would meet some resistance. > I can imagine something like %pV with unstable pointer. I don't see how %pV is different than any other current %p extensions. Rasmus