From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4528C33C515 for ; Sat, 7 Mar 2026 10:53:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772880793; cv=none; b=DtECFwJWVv/pesxm1yTsXb9QLZN9335+wvWtvozcNpVighWJned2DH2CH4YDq/YOJlzKPDO9qplk/6OeARarKGG2ohTI45p4466y2ho2D/BxUxAdO5X55qWE9TOEDD7V+ze+72NlSZI4ezBJJXPy4xDkwQ0G0UYFzsc3Zmrgdt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772880793; c=relaxed/simple; bh=tX+zmhVHD1eYhP5E6wE2H5i0PukkLTPqwEOQpxWn7Dc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ArG44R3FvQ0X2GGVT9SIWEs7TUXuEn2m3SUHsdCvRQtICSfu8Jz09A5BjLFXPVtqBbZQjuyVxIYNBl+1iUEhT+h+Mb+iMIrR22SD+FUNoEiGU6MecUGHOY557yWZ9L2pkW6Qi1VDAfL/ZUhs/Bsfj4C/4OhaQ9sOlzagphou6C0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=j5SviMr5; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="j5SviMr5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1772880790; bh=kyaGuwDVqA7Q0ceS/R3k/zCrVn7V6ODOnu0+otG4GBQ=; h=From:Message-ID:From; b=j5SviMr5qdfrr6uxmONsCtTlfPD9QsdDM57dw3KFDJSvBIqq72i6+I5rdNK9cFawK UoUSmIT8K2YCBAlaog/2J3xdu8GSeEbT11tWWFnBhxYhLh4b/FyNHl87teA2oYh91u k4fJuuggfO24k+/aEdyvGZGkkVPoyzSuRTCLTzWg= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 7F72CC0A16; Sat, 07 Mar 2026 11:53:10 +0100 (CET) Date: Sat, 7 Mar 2026 11:53:10 +0100 From: Willy Tarreau To: david.laight.linux@gmail.com Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH v4 next 00/23] Enhance printf() Message-ID: References: <20260302101815.3043-1-david.laight.linux@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260302101815.3043-1-david.laight.linux@gmail.com> Hi David, On Mon, Mar 02, 2026 at 10:17:52AM +0000, david.laight.linux@gmail.com wrote: > From: David Laight > > Update printf() so that it handles almost all the non-fp formats. > In particular: > - Left alignment. > - Zero padding. > - Alternate form "%#x" and "%#o". > - Field precision. > - Variable field width and precision. > - Width modifiers q, L, t and z. > - Conversion specifiers i, o and X (X generates lower case). > About the only things that are missing are wide chanacters and floating point. > > The tests are updated to match. > > Bloat/savings (in nolibc-test, but excluding the program) to patch 14: > (Measured for v3) > Function old new delta > _nolibc_u64toa_base.isra - 143 +143 > strerror - 78 +78 > __nolibc_sprintf_cb 58 91 +33 > itoa_r.isra 60 75 +15 > utoa_r.isra 144 - -144 > __nolibc_printf 1081 729 -352 > (All these functions include ~40 bytes for the stack protector code.) > utoa_r.isra and _nolibc_u64toa_base.isra pretty much cancel each other out. > itoa_r.isra grows slightly since it calls _nolibc_u64toa_base(). > strerror() used to be inlined, but over half of it is the stack check. > While some of the code added to __nolibc_sprintf_cb() has come out of > __nolibc_printf() 16-20 bytes is removed from the caller. > So there is a net saving of about 280 bytes (including losing a copy of > the number to ascii code). > > The later patches add code back in: > patch 13 - conversion flags " +#" +80 bytes > patch 14 - left aligning fields +38 bytes > patch 15 - zero padding and field precision +260 bytes > patch 16 - octal output +34 bytes > So probably about +130 bytes, but it will depend on what the application > actually calls and inlining decisions made by the compiler. > (All x86-64, other architectures will vary.) > > The biggest size change is probably removing the .data from strerror(). > This reduced the program binary file by 4k if it is the only initialised > data in a small program. Thanks for this work. I'm personally fine with the series overall, even though there are tiny comments here and there but nothing blocking. Let's wait for Thomas' finaly review however. I agree that having a more featureful printf() will definitely help in various areas since it's used a lot in low-level userland code and testing. Thanks, Willy