linux-kernel - Re: [PATCH 15/32] tools/nolibc: use intmax definitions from compiler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250304073742.GA9911@1wt.eu>
Date: Tue, 4 Mar 2025 08:37:42 +0100
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Shuah Khan <shuah@...nel.org>, Shuah Khan <skhan@...uxfoundation.org>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 15/32] tools/nolibc: use intmax definitions from compiler

Hi Thomas,

On Tue, Mar 04, 2025 at 08:10:45AM +0100, Thomas Weißschuh wrote:
> The printf format checking in the compiler uses the intmax types from
> the compiler, not libc. This can lead to compiler errors.
> 
> Instead use the types already provided by the compiler.
> 
> Example issue with clang 19 for arm64:
> 
> nolibc-test.c:30:2: error: format specifies type 'uintmax_t' (aka 'unsigned
> long') but the argument has type 'uintmax_t' (aka 'unsigned long long')
> [-Werror,-Wformat]
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> ---
>  tools/include/nolibc/stdint.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/include/nolibc/stdint.h b/tools/include/nolibc/stdint.h
> index cd79ddd6170e05b19945e66151bcbcf840028d32..b052ad6303c38f09685b645268dad1fa8848370d 100644
> --- a/tools/include/nolibc/stdint.h
> +++ b/tools/include/nolibc/stdint.h
> @@ -39,8 +39,8 @@ typedef   size_t      uint_fast32_t;
>  typedef  int64_t       int_fast64_t;
>  typedef uint64_t      uint_fast64_t;
>  
> -typedef  int64_t           intmax_t;
> -typedef uint64_t          uintmax_t;
> +typedef __INTMAX_TYPE__    intmax_t;
> +typedef __UINTMAX_TYPE__  uintmax_t;

Just thinking loud. While I understand the rationale behind this
change, it somewhat contradicts the one on printf where we explicitly
use it as an "unsigned long long" that's expected to be 64 bits:

   CASE_TEST(uintmax_t);    EXPECT_VFPRINTF(20, "18446744073709551615", "%ju", 0xffffffffffffffffULL); break;

Do we really have guarantees that a compiler will always declare
it as a 64-bit or unsigned long long ? E.g. we could see new
compilers decide that uintmax_t becomes 128-bit. Well, maybe in
that case it will simply be a matter of updating the test case
after all...

Willy