From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 C1A983385BE for ; Wed, 18 Feb 2026 22:57:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771455445; cv=none; b=OAiabJDcrc5I9BYF+cwGFAuTp3a14tgMLckhxX/k8iszk3gQQ0flTDj66oO9zzMjmoa6YC1gswQoRCn1NjDx4zOFu85SrszOdMQ641blBV0XafWjJkkG6KrXka6foSvAY83r4tx29G+CvCZ33a/B5frwasF3IXt21H8JzXUlsFk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771455445; c=relaxed/simple; bh=Y8vCdxjI51z0LGnBoC+/+yg2kubXy17UQI0G/c3vfyk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pVsMioopAI3RCXJAOXxt/JLrz+uWCjxdiTs8oIgYh06NsoR1jrGQbWtihej6vqkIE2C2nkYozJOwC3Am7ljmrkxdqnw07EXBHnwoFUVeLDvD3TVteWTClBROCeMTrlki+vbrwMs+YmgsPH8jQ6MPKNoVfYYNHQl94revNMERJ4g= 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=BE9kVQSW; arc=none smtp.client-ip=209.85.221.52 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="BE9kVQSW" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-436309f1ad7so233589f8f.3 for ; Wed, 18 Feb 2026 14:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771455442; x=1772060242; 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=lqkxZq+oYjIViwXB2G4FaoPChdb3nVRvybqHo7ZDCVg=; b=BE9kVQSWTv0inMT5NhPnSt9VEEjcgDgamhmfvqpaAZwdWM7uyfMJQPf9OivXwfOaZx ENDvYY40eq78JGetQsmqZjl3XPNkv6mq/g9SFj9g97roOVGJp9XUkPJhH7XgrkwLW9II YolpcwBTu3E3SgEhBUdqbsA7oOeGg/n+Xrv/o/3iZWlj6CIv47kM+AFGyuJBMktvWO3S WWVnhC2TF4zG9KFLDhILB3IYZN7vf8kxicebxTQfbyFFj6tmgZe5eczgM8udeyg9++wb K01lfUCMtsm3VrS4R7PYJXiYeSAibgGFjjq+aaGmnzgXGhB/wH/wkLJd1oXQKW4ArXTz X2mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771455442; x=1772060242; 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=lqkxZq+oYjIViwXB2G4FaoPChdb3nVRvybqHo7ZDCVg=; b=G1+amRCPMkfY91M5tcPc4QIbzV3pDeJ9LD/lZNLCYaOvMjPwV+8yPbisMno+HgbZMh KmzkoIu+RvfbJkAEz1SHL3pfb0zqhLDTywA/+/K2NSjEznOGhaiaqoYVGoR6UWvale9W Um6q031eDc5uJPs3hkA12AycNDLG/qakK8zmDOiUEOdYqAZPvnOj5Fj6sY8IIz+0YWzU ta18TaXXDIfUKVmAJi/d7F4ZSr/hX9A4+xQoyYAT40ARmkBVbzrAEJKWhmxjjUP23FNq FfWSSPp7DeLiZOO4lKtgdTgj8mEEeksvkwYy8jyqPIVfEGoMVYxFveTGyuRt0d3r5a0m tnNg== X-Forwarded-Encrypted: i=1; AJvYcCUHRjdaNeiPPJmulRR9IopxDTBc6dGlgOQu/JIQSUVdPebejMDi4QniiwXnQCTrzF0v6vGf543UCjIqOVs=@vger.kernel.org X-Gm-Message-State: AOJu0YyRirr1atILS8CkDjpKrPgMb7sRwZvQCkB2nACb5Y0+x5KoR+dq xKeSPnNGou+TL5HbBfB4G20+VzRXmP1u4vXrote5K3mMQROTYbBhQjNaLLKlhGCU X-Gm-Gg: AZuq6aIHyONZtzOC157xIVZEqkkZN7Uj9ZRQWdj5IhEVSC13CePxB4rgIKPZKeDEKuz e+hMNGqnD1c39qg1PAFM+FtI7Y6XyVOw1lzbgfvkZHcdF6S3zqARwNfJVkZY80iSUFAz7GRDhXl TT9AsFT+ZsNDhSkAWCGPC/yI5qgylIQntCouLtZnIXniXBHsPCELZbhKjyAt2Cx3jWjxL3pKHJE Y0N2a+Dv4zJ+rW+q5z9chTBSTDD+GpvqErUo74i8rbNWgqRltV8mrPjl2elWIfkC20H3l+Go17Y MkLs7D4fGvTfs5D/102t7tiXrxSMdDxBtl7/Qtk9FevHPy1D4emW6MGEhjZX3kMTVL7KIl0+fCF MNRq1f5I1bX4BwXDnpLqwUovhoI9BEpPGabMSi5uUhA4OzBLZLVKy9GpkQEX1lIYLyz72BnRh93 IEV8xw2XhJgXPoJ5v+R05ImnqjKh1wznmVuIQHTXgRecFx2/lKqs93eTtyubgTe1WH X-Received: by 2002:a05:6000:1865:b0:430:f449:5f18 with SMTP id ffacd0b85a97d-4379dba6f87mr35316334f8f.46.1771455441852; Wed, 18 Feb 2026 14:57:21 -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-43796ad009bsm43505516f8f.39.2026.02.18.14.57.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Feb 2026 14:57:21 -0800 (PST) Date: Wed, 18 Feb 2026 22:57:20 +0000 From: David Laight To: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= Cc: Willy Tarreau , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH v2 next 06/11] tools/nolibc/printf: Use bit-masks to hold requested flag, length and conversion chars Message-ID: <20260218225720.3ef4e0ba@pumpkin> In-Reply-To: <48966a82-3bd3-434c-abba-3984e45088e5@t-8ch.de> References: <20260206191121.3602-1-david.laight.linux@gmail.com> <20260206191121.3602-7-david.laight.linux@gmail.com> <74f30662-2481-47eb-bfef-2195b170f4af@t-8ch.de> <20260216224736.518df26e@pumpkin> <48966a82-3bd3-434c-abba-3984e45088e5@t-8ch.de> 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 Wed, 18 Feb 2026 18:36:28 +0100 Thomas Wei=C3=9Fschuh wrote: ... > > > With signed chars I get: > > >=20 > > > sysroot/i386/include/stdio.h:321:37: error: comparison is always fals= e due to limited range of data type [-Werror=3Dtype-limits] > > > 321 | (ch < (cmp_1 & ~0x1f) || ch > (cmp_1 | 0x1f) ? 0 : \ = =20 > >=20 > > Stupid type-limits warning. > > It is almost impossible to get rid of without making the code unreadabl= e. > > =20 > > > | ^ > > > sysroot/i386/include/stdio.h:389:35: note: in expansion of macro '_NO= LIBC_PF_CHAR_IS_ONE_OF' > > > 389 | ch_flag =3D _NOLIBC_PF_CHAR_IS_ONE_OF= (ch, 'c', 'd', 'i', 'u', 'x', 'p'); > > > | > > >=20 > > > This can be fixed by switching 'ch' to be always unsigned. =20 > >=20 > > That's likely to provoke another error elsewhere. > > In any case optimising that test away makes the code smaller! =20 >=20 > We will need to get rid of this warning in some way. > Using pragmas in nolibc proper is something we don't want to do. I think I've a version that won't generate the warning. Not that I get it from the version of gcc I'm using. Just changing the ch to +ch might be enough, and the optimiser will still optimise to a single signed compare. >=20 > > > You can run the the builtin test suite like this: > > > -p triggers the download of the toolchains > > > -l uses LLVM/clang instead of the downloaded toolchain > > >=20 > > > $ cd tools/testing/selftests/nolibc > > > $ ./run-tests.sh -m user -p > > > $ ./run-tests.sh -m user -l =20 > >=20 > > I've just been running: > > rm nolibc-test; make -O /path/.../dir && ./nolibc-test printf =20 >=20 > This will miss weird things going on between different architectures. > Probably not directly relevant for changes to printf, but still useful. > And it shows the type limits warning. >=20 > > > > + > > > > typedef int (*__nolibc_printf_cb)(void *state, const char *buf, si= ze_t size); > > > > =20 > > > > static __attribute__((unused, format(printf, 3, 0))) > > > > int __nolibc_printf(__nolibc_printf_cb cb, void *state, const char= *fmt, va_list args) > > > > { > > > > - char lpref, ch; > > > > - unsigned long long v; > > > > + char ch; > > > > unsigned int written, width; > > > > + unsigned int flags, ch_flag; > > > > size_t len; > > > > char tmpbuf[21]; > > > > const char *outstr; > > > > @@ -265,6 +290,7 @@ int __nolibc_printf(__nolibc_printf_cb cb, void= *state, const char *fmt, va_list > > > > break; > > > > =20 > > > > width =3D 0; > > > > + flags =3D 0; > > > > if (ch !=3D '%') { > > > > while (*fmt && *fmt !=3D '%') > > > > fmt++; > > > > @@ -274,6 +300,14 @@ int __nolibc_printf(__nolibc_printf_cb cb, voi= d *state, const char *fmt, va_list > > > > =20 > > > > ch =3D *fmt++; > > > > =20 > > > > + /* Conversion flag characters */ > > > > + for (;; ch =3D *fmt++) { > > > > + ch_flag =3D _NOLIBC_PF_CHAR_IS_ONE_OF(ch, ' ', '#', '+', '-', = '0'); > > > > + if (!ch_flag) > > > > + break; > > > > + flags |=3D ch_flag; > > > > + } =20 > > >=20 > > > What is the advantage of this over: > > >=20 > > > while (1) { > > > /* ... */ > > >=20 > > > ch =3D *fmt++; > > > } =20 > >=20 > > One line shorter :-) =20 >=20 > Meh. Let's not optimize for that. Actually I looked at that code again. The outer 'ch =3D *fmt++' can be put inside the loop. It was outside the 'width' code and I inserted that bit in the gap. ... > > > Why separate input and ouput arguments instead of one combined one ('= +r')? > > > I have been wondering the same about the kernel definition, too. =20 > >=20 > > I'm not sure either. > > Certainly "+r" is more modern - which is why it isn't used in a lot of = places. > > They may be identical (indeed "+r" might get converted to the "0" form), > > but maybe it gives better separation - I just copied the same version. = =20 >=20 > Okay. We use '+r' in the syscall wrappers, so availability should not be > an issue. But I don't really care on way or another. "+r" seems to work - I will use it. David >=20 >=20 > Thomas