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 09F7A28CF77 for ; Sun, 8 Feb 2026 17:31:21 +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=1770571882; cv=none; b=l0/o/cxOtjtLOa0XUGuRN3XstzO7YE4hwJQB9ToFz7S4/Ai7ryC2pBlsMy2kIs2knYeUsMy9aimLe9O4gj2vusmxnDmA89rBvpZ+U4PmpHN+4eFEnFwHlajPURJN3uGI8Dr1lktwOypInYFUX5bYOiLW1vY1MGtvRmVTuqzVVes= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770571882; c=relaxed/simple; bh=YNYWnFIzh4DxyGswH6J6MQTtyhTgTtUJgY7ezimJDFU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o64z16uQv5yOGhVstooIeK8OOOLEV2J1BYPMDCcRr3WHiPZIL0XgjVic76K1WjBOB/2i/d3988H4pab80aTJfn9rGXtwWaFJ3l5KovAVOzBMeke6CWRmHdi7zRu1obh0Km3xIoX7BkuERwyi1u3SsstK2Pljqk5TfxDP59x+A74= 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=ZKK/dtyI; 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="ZKK/dtyI" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-482f2599980so44193625e9.0 for ; Sun, 08 Feb 2026 09:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770571880; x=1771176680; 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=gpiARNYLCw2zd63v747Kv2Zk6E+yV0i6E+te++PEPGE=; b=ZKK/dtyI+3UHkngulQYAMNWFEHAB49ssm+Q7qEKMP4F96aLAeTxHI8RBqe4xX4tgyc 64h/90hn+MvxMXlQOhz1sWdBZSkCBr+vL6vtXqn0DFKEfnCjWHHLQBDIO1a4e3ROL2+N CxtSFfiD8KYXiyqNFRPuRpPHNmOamYRnIcHdWol0ttC6mkz5Sv/7SbBJfMVHJSw6p3u1 9Gbzl04iqrp1SkIw9fF6Vt8CV5cnN1mkjjYTg+iWdfXKuMlwfFJJt6P20goz8a9fmj8M 1Qm5+IBC/Sl4NM08ni/iL9gulC1qLbkhtOPh5xdSDv/tlbILig/cKjsohWMICiTH2Z6a MZ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770571880; x=1771176680; 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=gpiARNYLCw2zd63v747Kv2Zk6E+yV0i6E+te++PEPGE=; b=qx8RUc+wajBjeAcimrwZKRoIUXHvD59z8+ZFrmRC6lsxzUVj8/cSaruLpaHYGavUNb 878ozsOGTCbg0xEfCAtW/JvFkVm//xUL2IPdrUQ2ibn/emAherbnVR3ffb5uT+yDLeSK T6E9nAEPRY0SdZnATtieWlv0pxRJlqTBkYm69yS87RW1WiI8Yjo1Jf6iYl4SgoXjptIE BaPG/IiH80elpTjKGSs1RzoqhtJBZWbFAFCxB+XjH0GNmokFcE2anPhTrOFKgIhFDLcJ W6r9wv8hb9klJbwySysFveAoiJ8VyRfhydOGE8rG0A2HLZA2cOEKNFRsdbXFcvyMV/z5 /PpQ== X-Forwarded-Encrypted: i=1; AJvYcCX+8NT6f10T3c6V+cLnDbkZa/CP1Y6axfMDrlL9NUaO4r9a17heCrFyOOV6cD9rHNidKS9bZGZQCGFRgbI=@vger.kernel.org X-Gm-Message-State: AOJu0Yxs60/wASN0SKDwdpO/I0ipYO7gfM1GolSjbdnK79CwGIs9vZ5Y fdiVibo8LSCyU7YFqu2xf+dCEFAiMp3ENkxWMSQfc5T1pylrdb5bu3z7 X-Gm-Gg: AZuq6aJrtmScNkCaEIHTvKexpvK21EO7ksxXlus2y+ZX/SuqR3LeFgAjtFrCFJnQle8 cKlMnJti9XicQXbazNxA7ygFZBNVW8F4MyE8G9vsn01omRlrVS5FwsoLC0cOfzH9i8CNf7clXuW ItG9gnRFlyQmi7cEPeIAvse2fDMiaSohqf4LYKhD5S5z6uXuYz7eAbpNv/r+jAww1tm49WstOZ/ nogeD6cLzS3a2bd46FVkVhlVJLcUSkeTQDkUvtnMnzdu2o5sIjk78u9F5Zs+ZHm/N8mOMdzRfLX Atea/U8hqobymeC8QN5XwskMfwW1o+TJD2PKhD6gSSnCx5/v6SD5LwIFJVWCWXjjQwM+avLA+rK 03BzoPHePM7gJU/B1q0CToYBUaPkKHiFwq0ZIwlMZE1tbVnaZi9cKLPSMPt32ZDNZLK6I40LnUu bRMDZ3we+rJTXcMCX2JkOme13gee3k0RdO+E9cIpFLFddPfAoBgEkK X-Received: by 2002:a05:600c:6290:b0:483:a21:774a with SMTP id 5b1f17b1804b1-48320225afemr140871375e9.26.1770571879928; Sun, 08 Feb 2026 09:31:19 -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 5b1f17b1804b1-48320728774sm178910875e9.14.2026.02.08.09.31.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Feb 2026 09:31:19 -0800 (PST) Date: Sun, 8 Feb 2026 17:31:18 +0000 From: David Laight To: Willy Tarreau Cc: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH v2 next 08/11] tools/nolibc/printf: Add support for zero padding and field precision Message-ID: <20260208173118.4e565896@pumpkin> In-Reply-To: References: <20260206191121.3602-1-david.laight.linux@gmail.com> <20260206191121.3602-9-david.laight.linux@gmail.com> 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=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 8 Feb 2026 17:16:24 +0100 Willy Tarreau wrote: > On Fri, Feb 06, 2026 at 07:11:18PM +0000, david.laight.linux@gmail.com wrote: > > + /* Add zero padding */ > > + if (_NOLIBC_PF_FLAGS_CONTAIN(flags, '0', '.')) { > > + if (!_NOLIBC_PF_FLAGS_CONTAIN(flags, '.')) { > > + if (_NOLIBC_PF_FLAGS_CONTAIN(flags, '-')) > > + /* Left justify overrides zero pad */ > > + goto prepend_sign; > > + /* eg "%05d", Zero pad to field width less sign */ > > + precision = width; > > + if (sign) { > > + precision--; > > + if (sign >= 256) > > This is the one that confused me with previous patch. As long as we cannot > have 4 chars that's OK, otherwise the 4th char can flip the sign. We could > also add and unsigned cast here to clarify this, though admittedly this > should not change over time. The idea is that sign is 0/1/2 characters, a comment at the top might help. > Just for the record, this is the patch that increases the code the most > (+265 bytes for me, no jump tables). But I think the feature is worth it > and I'm not seeing low hanging fruits to reduce it. I honestly find the > code particularly complex to follow now but that's related to the > multiplicity of output formats and I doubt we can do much about this. The final complexity is why I posted the full final version. Trying to follow all the patches through is hard. Some of the early changes are arranged to make the later ones smaller. Yes it steals back all the gains from the previous patches and a bit more. If you add the 'divide by reciprocal' [iu]64to[ah]_r() patch I think you gain back at least two copies of the conversion code. That might make it a net win. The original code called u64toa_r(), u64toh_r() and i64toa_r() from the numeric conversion code and utoa() from strerror(). Each copy is about 150 bytes on x86-64. One copy is gone already, but I think there are two left. That might give octal conversion at no net cost, David > > Acked-by: Willy Tarreau > > Willy