From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DA9741C62 for ; Fri, 30 Jan 2026 14:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769785086; cv=none; b=VK8RojD9ZdmCf/uqIL202A4ejLmL60jNi6jr1qf0GlGwMeVbHTEMJqFZjKoQSLdQ0xaInJ1KNGzhahuHFBAMxV0RV9P6I0zVhnBc4WkCYgEr3PE1V2uLgwUFbFODTMc2GuYhHfkUthtsDckEjwvDQh/LK7k4bj3HmJweVFyZfgs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769785086; c=relaxed/simple; bh=K9vtUp9xvZ77T4o0EWREyyPBz7hlMk5Pf4jsQnnLnQc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EUapRiNI78N1bKLunetX8FCY4ezjznU93o6TIyFfVyGSXdbgw82cD3zFStoOtiGBsgEOjJaqiyFIMerZrnb0XUZ9f+l6kEhYVyDJBj06MHNNm2bHlYT7gVAGbAC2LiY+TDoyE9YGHL8VgzdQzWYphQivXClCw4/JPM2rq+pI11w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TIy87Fup; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TIy87Fup" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4806b43beb6so17036415e9.3 for ; Fri, 30 Jan 2026 06:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769785083; x=1770389883; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=PZNbvfTujDNji+OmkGwlD51VEMDpE050+cE6LK49zxg=; b=TIy87FupRqQoO9Yxnj1+T/6EKtecKkm4JbxOOY2IgIDjeEQg51lh9VYnPpfh40k8yQ JcmiWcbMByCXdiF7HWytPV9PFmTASqWVBFD+yQSIqjlD/u66JwbWynCZm0x9YhULfHnj Fqb6r8wbXntzh3drOGFhOJ+1Q6B3YYdx3GpHELH8+6ws5CfGcIuHiMuREQVA4KaqUGVC 8cgxOPkDNcSHZLjq9RIfaxjBUnJlep9LJonx/Mtc8n35HPSMih7AVgX0Qd9a8MoEdfLx f8PEafVgYOqFICbKlbq7Z/nQelB3TcDkVgcfj2v9d1KzoJ+iaGmPYem35yWpIB5Lk0AC nndA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769785083; x=1770389883; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PZNbvfTujDNji+OmkGwlD51VEMDpE050+cE6LK49zxg=; b=XRgXPAqlDm4TWvAnE5VuPPfPBog2uisXqthqDO3oDBjf7gHlm/CFOtXpY0cqnIZLkF w5jmTxt8usTmxHzDQOShEctI6sDDviCwZ0Ry/udCESeLMobdq5ixAwF3Bahek1ws/l4+ Zw2GujuN4FsZcds6IkgUhtTNp/Yy8i9MX+1BJ3SyInssIxOvoAywkAYPCGzKV3S1DwWn GbjJAI1cI90CotLxHn6/fJgYR2QXeN4e6pMYaNIAfjzg1etjvse6KYWo55ywpyCRN2Qo xNZwF19j/5ehkyE6dpxpP8e4aZQC/Iovg97E2LqIAXMq1Efy4Vj4nTS5JyQYPMRfwaLv 9Kfw== X-Forwarded-Encrypted: i=1; AJvYcCUIJlDjTwZRTVf1L2Q3ULrimWDaZyIAGPVnqr8A7Ar0cscaFpLKCCncYlI8tegOJGSA1xba+sm+JVzFyEU=@vger.kernel.org X-Gm-Message-State: AOJu0YwlbiWQl/5q5zbjggAyZ7kOnGil7yUCs8RB4SIJEjjnqzhecapN /vhn9yTYhPadPulLxS9gp9gE0M4rgBLVGwOQ19h1BnZW2Rm/983UgXIw X-Gm-Gg: AZuq6aIFmPoXccSdhjAVXr3V6wCQdA8izyFFyrVWtYgGpMKyJFVPL1l061MliJr0kGf iZ0yEcBblsmdOHuUKQMhO0qGWuCBNEWTgoy2BZqJGAkELAyaMrxuZoL/EowAxJszd4bzFycmTMz puBJV4mNkNdz/9JXwlMcqzOQbH2Zsy2WJXc4kEVniX1WPFZTm3YRB9QGG5AUyUlZx7Mq6JW8DDV NRa1Z9JYuaixDjKzjkZ63rADlvQyI3vVbBseuugc/yeZDwEYjJ/Pu2fSRLYM5RIzqgSvoqFL4FB IDoT7+19Sh4tEl8C55PzROBWXBEICrXPYucG+k5xAO4J8V9G/n6EwBy92eFrDJZlzF9+o/mVFJs zz3W2Fntir1U+Vd6Mnqk8dmFSjq1mLv+36wZt5NjPE4ZOc8XdLVbguhOaPgsNbr99Mm38EMqj0p r6r/4a1WtCRnfNJocXP4dMzXjf5bS2+My3cawqiRH4smcs33X1atA1 X-Received: by 2002:a05:600c:4fd5:b0:477:a219:cdb7 with SMTP id 5b1f17b1804b1-482db213bc7mr39397365e9.0.1769785083184; Fri, 30 Jan 2026 06:58:03 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e13235f5sm22251483f8f.29.2026.01.30.06.58.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jan 2026 06:58:02 -0800 (PST) Date: Fri, 30 Jan 2026 14:58:01 +0000 From: David Laight To: Cheng Li Cc: Willy Tarreau , Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] tools/nolibc: add support zero pad (0) in printf Message-ID: <20260130145801.01d3908e@pumpkin> In-Reply-To: References: <20260130083737.1123-1-im.lechain@gmail.com> <20260130100252.343902c6@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 30 Jan 2026 18:12:48 +0800 Cheng Li wrote: > David Laight =E4=BA=8E2026=E5=B9=B41=E6=9C= =8830=E6=97=A5=E5=91=A8=E4=BA=94 18:02=E5=86=99=E9=81=93=EF=BC=9A > > > > On Fri, 30 Jan 2026 16:37:35 +0800 > > "licheng.li" wrote: > > =20 > > > From: Cheng Li > > > > > > This patch correctly implements the '0' flag in __nolibc_printf() to > > > allow zero-padding for numeric and pointer outputs. > > > > > > Thanks to David for pointing out the errors in the previous implement= ation. > > > > > > The logic ensures that the sign ('-') for negative numbers or the pre= fix > > > ('0x') for pointers is printed before the padding zeros, adhering to > > > standard printf behavior (e.g., producing "-0005" instead of "000-5")= . =20 > > > > I think it would be much better to change the contents of tmpbuf[] > > where it is filled with the converted number. > > You'd need to limit the number of zeros added (or the precision) to (sa= y) 32 > > and then set 'outbuf =3D tmpbuf + 32' so that the zeros and sign/0x can= be > > added at the front. =20 >=20 > Hi David, >=20 > You are absolutely right. Modifying the buffer generation logic > (tmpbuf) is indeed > the robust way to handle sign/prefix insertion combined with padding/prec= ision. > My current approach of trying to handle it during the output phase is > too fragile > and misses edge cases (as I also realized regarding the negative sign iss= ue). >=20 > Given the complexity you mentioned (like the subtle differences in > standard compliance) > and your plan to implement full field precision, I will drop this > "Zero Padding" patch entirely. > It is better implemented as part of a proper precision support overhaul. >=20 > I will focus on the "Left Alignment" patch. I am sending out v4 of > that series later, > which incorporates the code-swapping optimization you suggested earlier. >=20 > Thanks for the detailed feedback. A good plan :-) I've written support for "%[#+- 0]*[.*][duxp]" but not tested the new bits = yet. That is at +175 bytes after I used OPTIMZER_HIDE_VAR() to stop the compiler making a 'pigs breakfast' of the code (added nearly 100 bytes for a simple = if() to avoid everything when the value and precision are both zero). David