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 9B9C132B982 for ; Wed, 28 Jan 2026 07:55:30 +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=1769586932; cv=none; b=A/xydsVfzFCBzF8+TQCxAMwUuD+QiXbieu2Z8+gdFUYMuflQFSrq340YLKI3OR2tw+r823ZU7fxxFMOvL5R+Pmk52YZmSq2kr8jQAuPR4lHDEJBccJfTOrzFa0mwlCpJppYxD6mroYWowclxhXE3m/SVNkW1Q7FijmhnPA99XYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769586932; c=relaxed/simple; bh=ZGcRPRA3SytT1wL39Rsg/wybOOCLly1SbdrhREx2ZiM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dUvwtZ+dqrKfNusAOJppO+e8AiMSVe3L9e3J3iDajFHS4BihlD7L6TrmNsj1GfTB4X+HYxO2mGIorzmytLMHIKzdXX7wg3iZGX8a5/A6uhur/4q4boCXg0xfWUUtKS0ljUhz7UjglHthNw1celPEe9sxIgOb44gBg7K8yG9nglw= 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=wAWld1kL; 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="wAWld1kL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1769586449; bh=oV4j11bKl5LmwblLBQ7k+e7M36s88/Ijx6Ic6G2RcUM=; h=From:Message-ID:From; b=wAWld1kLYMt7LBpd6mdBPiu9Luug9gVsqLb8MDskubEDIjtAo6XTXhCbDZ2mGu8sU vAPUMzsn3VXZ9JQf8ceOXoAGW07BnE0YqkEEHazH+hti3RlA7HYkU8JsBWAcSxk3Rh aITWjHSwfNr0dNXSwMd4AAbZnF2Efln5cxw0luJA= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id F3629C0A52; Wed, 28 Jan 2026 08:47:28 +0100 (CET) Date: Wed, 28 Jan 2026 08:47:28 +0100 From: Willy Tarreau To: "licheng.li" Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] tools/nolibc: support left-aligned printing in printf Message-ID: References: <20260126031038.35387-1-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: <20260126031038.35387-1-im.lechain@gmail.com> On Mon, Jan 26, 2026 at 11:10:37AM +0800, licheng.li wrote: > From: Cheng Li > > Currently, __nolibc_printf() in nolibc does not support the '-' flag > for left alignment. This limits the ability to format tabular output > nicely. > > This patch adds support for the '-' flag. The implementation is kept > minimal to minimize the binary size impact. > > Measuring the nolibc-test binary on x86_64 shows a small increase in > the text section: > > 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. > > Signed-off-by: Cheng Li > --- > tools/include/nolibc/stdio.h | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/tools/include/nolibc/stdio.h b/tools/include/nolibc/stdio.h > index 1f16dab2ac88..b90b59237bda 100644 > --- a/tools/include/nolibc/stdio.h > +++ b/tools/include/nolibc/stdio.h > @@ -250,7 +250,7 @@ typedef int (*__nolibc_printf_cb)(intptr_t state, const char *buf, size_t size); > static __attribute__((unused, format(printf, 4, 0))) > int __nolibc_printf(__nolibc_printf_cb cb, intptr_t state, size_t n, const char *fmt, va_list args) > { > - char escape, lpref, c; > + char escape, lpref, padc, c; > unsigned long long v; > unsigned int written, width; > size_t len, ofs, w; > @@ -261,11 +261,17 @@ int __nolibc_printf(__nolibc_printf_cb cb, intptr_t state, size_t n, const char > while (1) { > c = fmt[ofs++]; > width = 0; > + padc = ' '; > > if (escape) { > /* we're in an escape sequence, ofs == 1 */ > escape = 0; > > + if (c == '-' || c == '0') { > + padc = c; > + c = fmt[ofs++]; > + } > + > /* width */ > while (c >= '0' && c <= '9') { > width *= 10; > @@ -358,13 +364,19 @@ int __nolibc_printf(__nolibc_printf_cb cb, intptr_t state, size_t n, const char > if (n) { > w = len < n ? len : n; > n -= w; > - while (width-- > w) { > - if (cb(state, " ", 1) != 0) > + while (padc != '-' && width > w) { > + if (cb(state, &padc, 1) != 0) > return -1; > written += 1; > + width--; > } > if (cb(state, outstr, w) != 0) > return -1; > + while (width-- > w) { > + if (cb(state, " ", 1) != 0) > + return -1; > + written += 1; > + } > } > > written += len; Thank you, this looks good to me. Since you have paid particular attention to the size increase, I noticed a few tricks which help a little bit here: - increment written at the beginning of the loop instead of the end helps the compiler make the code more compact. - testing width > w before padc != '-' also helps by benefitting from the result of the last iteration's increment: while (width > w && padc != '-') { written += 1; if (cb(state, &padc, 1) != 0) return -1; width--; } ... while (width-- > w) { written += 1; if (cb(state, " ", 1) != 0) return -1; } $ printf '#include "stdio.h"\nvoid *p = printf;\n' | gcc -Os -xc -c -o printf.o - $ nm -oa --size printf*o|grep 'printf$' printf-before.o:000000000000035f t printf printf-licheng.o:00000000000003b5 t printf printf.o:00000000000003a3 t printf => that's 19 less bytes, or almost 10% smaller ;-) I also tried changing the 3 blocks for a single loop checking width and w to call cb() once and adjust written/w once but it gave the exact same size for less efficient code so that was not worth it. Anyway, just to say that if you're interested in trying the minor adjustments above, you're welcome, otherwise I'm fine with this patch. Thanks! Willy