Re: [PATCH] coreutils/printf: fix errno clobbering with glibc 2.43

On 16/03/2026 14:23, David Laight via busybox wrote:
> On Mon, 16 Mar 2026 12:40:59 +0530
> Hemanth Kumar M D via busybox <[email protected]> wrote:
> 
>> glibc 2.43 enabled 2MB Transparent Huge Pages (THP) by default on arm64:
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=321e1fc73f53081d92ba357cdd48c56b79292020
>>
>> This causes malloc() to set errno to ENOENT in some cases on arm64,
>> even with successful allocations. busybox printf uses errno as an
>> accumulator and returns exit code 1 if errno is non-zero. Since glibc
>> 2.43 unexpectedly sets errno during successful printf() calls, busybox
>> printf returns exit code 1 even when output is correct:
>>
>>     FAIL: printf understands %s '"x' "'y" "'zTAIL"  (exit 1, expected 0)
>>     FAIL: printf handles positive numbers for %f      (exit 1, expected 0)
>>
>> Note: the printf output itself is correct in both cases — only the
>> exit code is wrong.
>>
>> Fix by saving and restoring errno around each printf() call in
>> coreutils/printf.c, only preserving a non-zero errno if an actual
>> error occurred (ret < 0).
> 
> That seems like the wrong fix for the problem - but your patch is mangled.

It looks like the right fix to me. It also doesn't look mangled to me.

> If malloc() is allowed to set errno when it doesn't fail (I can't remember)
> then the same will be true of printf().
> (And at least some implementations of printf() end up calling malloc() for
> for floating point formats.)

Yes, that's exactly the problem that the patch addresses.

> In any case looking at the return value from fprintf() isn't particularly useful.
> If buffering is enabled (typical for files) then nothing can fail until the
> buffer is flushed during close().
> If you actually want to check for printf() failing when you need to call
> fflush() and then check ferror().

This is not relevant. The patch isn't to change the handling of errors, 
the patch leaves that entirely unchanged. The patch is only to ensure 
that the error handling is *not* invoked when there is no error.

Cheers,
Harald van Dijk
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox