From: Thomas Weißschuh thomas.weissschuh@linutronix.de
[ Upstream commit e5407c0820ea5fa7117b85ed32b724af73156d63 ]
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@linutronix.de Acked-by: Willy Tarreau w@1wt.eu Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES** This commit should be backported to stable kernel trees. ## Detailed Analysis: ### Code Changes Analysis: The commit makes a targeted fix to `tools/include/nolibc/stdint.h` by replacing: ```c typedef int64_t intmax_t; typedef uint64_t uintmax_t; ``` with: ```c typedef __INTMAX_TYPE__ intmax_t; typedef __UINTMAX_TYPE__ uintmax_t; ``` ### Problem Being Fixed: This addresses a **compiler format checking incompatibility** where: - The compiler's printf format checking uses intmax types from the compiler itself, not from libc - This mismatch causes compilation errors with clang 19 on arm64 - The error occurs because nolibc defined intmax_t as `unsigned long long` while the compiler expected `unsigned long` ### Evidence Supporting Backport: **1. Similar Pattern Match:** This closely follows the pattern of Similar Commit #4 and #5 (both marked YES for backport): - Similar Commit #4: Fixed integer type definitions for 32-bit platforms (backported) - Similar Commit #5: Fixed printf format mismatches with compiler warnings (backported with Cc: stable@vger.kernel.org) **2. Bug Fix Nature:** This is clearly a **bug fix** that: - Resolves compilation failures with clang 19 - Fixes format checking incompatibilities between compiler and library definitions - Affects actual build failures, not just warnings **3. Low Risk/High Impact:** - **Minimal change scope**: Only changes 2 typedef lines - **Contained to nolibc**: Affects only the tools/nolibc subsystem - **Uses compiler-provided types**: More robust than hardcoded definitions - **Fixes build breakage**: Critical for users with newer compilers **4. Aligns with Stable Criteria:** - Fixes important build issues affecting users - Small, contained change with minimal regression risk - No architectural changes or new features - Resolves compatibility with current/newer toolchains **5. Historical Context:** From the kernel repository examination: - Previous similar format-related fixes (commit 92098b1c10cb) were already tagged for stable with `Cc: stable@vger.kernel.org` - The nolibc subsystem has a history of backporting compiler compatibility fixes - The pattern of using compiler-provided types (like `__SIZE_TYPE__`) is already established in the codebase **6. User Impact:** This prevents build failures for users with: - clang 19 on arm64 - Potentially other compiler/architecture combinations where intmax_t definitions differ - Any nolibc-based applications or tests The commit represents exactly the type of fix that stable trees are designed for: a small, targeted fix that resolves build breakage without introducing new features or architectural changes.
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 cd79ddd6170e0..b052ad6303c38 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;
/* limits of integral types */