From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753521AbbKZVKz (ORCPT ); Thu, 26 Nov 2015 16:10:55 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:35630 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752640AbbKZVKw (ORCPT ); Thu, 26 Nov 2015 16:10:52 -0500 From: Rasmus Villemoes To: Andy Shevchenko Cc: Andrew Morton , "linux-kernel\@vger.kernel.org" Subject: Re: [PATCH 06/14] lib/vsprintf.c: warn about too large precisions and field widths Organization: D03 References: <1448314171-25856-1-git-send-email-linux@rasmusvillemoes.dk> <1448314171-25856-7-git-send-email-linux@rasmusvillemoes.dk> X-Hashcash: 1:20:151126:andy.shevchenko@gmail.com::j8ioHsIkTMMTgTdS:0000000000000000000000000000000000001B6O X-Hashcash: 1:20:151126:linux-kernel@vger.kernel.org::KOOhj1meXwXiExnk:0000000000000000000000000000000000h4+ X-Hashcash: 1:20:151126:akpm@linux-foundation.org::TGuTbScjsSroCrVK:0000000000000000000000000000000000002tUS Date: Thu, 26 Nov 2015 22:10:48 +0100 In-Reply-To: (Andy Shevchenko's message of "Tue, 24 Nov 2015 00:34:12 +0200") Message-ID: <87610oeaav.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: >> The field width is overloaded to pass some extra information for >> some %p extensions (e.g. #bits for %pb). But we might silently >> truncate the passed value when we stash it in struct printf_spec (see >> e.g. "lib/vsprintf.c: expand field_width to 24 bits"). Hopefully 23 >> value bits should now be enough for everybody, but if not, let's make >> some noise. >> >> Do the same for the precision. In both cases, clamping seems more >> sensible than truncating. While, according to POSIX, "A negative >> precision is taken as if the precision were omitted.", the kernel's >> printf has always treated that case as if the precision was 0, so we >> use that as lower bound. For the field width, the smallest >> representable value is actually -(1<<23), but a negative field width >> means 'set the LEFT flag and use the absolute value', so we want the >> absolute value to fit. >> > > Do we need to do the same for bstr_printf() ? > Heh, apparently I didn't learn anything from 762abb51. Thanks, will fix in next spin. Rasmus