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 A1565376BC9 for ; Thu, 29 Jan 2026 07:07:12 +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=1769670435; cv=none; b=pSEbYmciFN7PkveIHn3l0SJJFk230msH59Rc7pvPyNldnisA86BmmdkM86Qu4bkEMvhtVGvRB3d73G/zEGGD7pIu2Qz3sQzwpT22lmBxZSafteDhMgE7HgV3DgRoh80sC4wFerL42Md1lT1+vwBStpJKRHLX2emtZUdbAHOx1T0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769670435; c=relaxed/simple; bh=GT7BmD/uBaX2xXNes7sGAm2gzUnllgBmIbII2KN5ATA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X2uYpDWC0Y0njmvG1mGtiOO8z99H9xf+2JPTHX+VAmarKBe6jRqN2fSm7xaDnoCWiNYnla31ifUF/NhhRgS2fdouuIzpGOGblzk3uAaZxiQ0btTyDDSTbD7Lvdr4pz5BEx/z4+lv1tpwIq5Hnr7jC5VFCsM1ikxtp28g7CUOFGE= 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=uQ8OypfS; 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="uQ8OypfS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1769670430; bh=sgBOdh0Jj0LKeHO5jk7AwU0ChbSrPS5ufTFHVXXMRZE=; h=From:Message-ID:From; b=uQ8OypfShlMarIOs7aI3T9tEBEM3SqashsfWYvWxLF1YqFTiEyzYnBhc1WhFp1mPY DOPKiC0jpImZtlsA8b1aBfxthSEJgqZG08hRkGcfA2wRC1A42w1BK8fwxXp3vQDqap hv4TJGezCTeRMGNXJmnt1ec/v0c5WOTViWY3nKn4= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id C47BBC0A3D; Thu, 29 Jan 2026 08:07:10 +0100 (CET) Date: Thu, 29 Jan 2026 08:07:10 +0100 From: Willy Tarreau To: licheng Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] tools/nolibc: support left alignment (-) and zero padding (0) in printf Message-ID: References: <20260128094224.11299-1-im.lechain@gmail.com> <20260128094224.11299-2-im.lechain@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: On Thu, Jan 29, 2026 at 02:57:26PM +0800, licheng wrote: > Hi Willy, > > Willy Tarreau ?2026?1?29??? 14:41??: > > > > Hi Cheng, > > > > On Wed, Jan 28, 2026 at 05:42:23PM +0800, licheng.li wrote: > > > From: Cheng Li > > > > > > Currently, __nolibc_printf() in nolibc parses the width field but always > > > pads with spaces on the left. It ignores the '-' flag (left alignment) > > > and treats leading zeros in the width as part of the number parsing > > > (resulting in space padding instead of zero padding). > > > > > > This patch implements support for: > > > 1. The '-' flag: forces left alignment by padding spaces on the right. > > > 2. The '0' flag: forces zero padding on the left instead of spaces. > > > > > > The implementation reuses the padding character logic to handle both > > > cases. > > > > > > Logic behavior: > > > - "%5d" -> " 12" (unchanged) > > > - "%-5d" -> "12 " (new: left align) > > > - "%05d" -> "00012" (new: zero pad) > > > - "%-05d"-> "12 " (new: left align overrides zero pad) > > > > > > The code is optimized to keep the binary size impact minimal. > > > Measuring the nolibc-test binary on x86_64: > > > > > > text data bss dec hex filename > > > 43552 248 112 43912 ab88 nolibc-test (before) > > > 43677 248 112 44037 ac05 nolibc-test (after) > > > > > > The net increase is 125 bytes. > > > > Is it normal this didn't change since previous patch, or did you just > > forget to update that part of the commit message? In my case I'm seeing > > a difference: > > > > text data bss dec hex filename > > 35964 112 120 36196 8d64 nolibc-test-before > > 36070 112 120 36302 8dce nolibc-test-after1 <- first patchset: +106 > > 36044 112 120 36276 8db4 nolibc-test-after2 <- this patchset: +80 > > > > If it's just an omission, I can edit the commit message if you paste > > the new before/after in response, and save you from a respin just for > > this! If it didn't change anything, that's possible as well, but > > surprising, which is why I preferred to ask. > > Thanks for catching this! You are right, I missed updating the binary > size data in the v2 commit message. I performed the previous measurement > using the simplest command: `make -C tools/testing/selftests/nolibc' OK! > The discrepancy in absolute numbers is likely caused by the different compiler > versions and optimization levels between our environments. Since your > environment > shows a more accurate delta for the current upstream state, please feel free to > update the commit message directly to save a respin. OK will do. I'll handle this this week-end unless Thomas has other comments or beats me at it. In case I forget, do not hesitate to ping me early next week ;-) thanks, Willy