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

Reply via email to