linux-kernel - Re: [PATCH] tools/nolibc: Add stdbool.h to nolibc includes

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: <871aa6e4-21ef-493c-9eac-df9b8069afab@weissschuh.net>
Date: Thu, 25 Sep 2025 16:46:11 +0200 (GMT+02:00)
From: Thomas Weißschuh <linux@...ssschuh.net>
To: André Almeida <andrealmeid@...lia.com>
Cc: Mark Brown <broonie@...nel.org>, Willy Tarreau <w@....eu>,
	linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
	Ingo Molnar <mingo@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
	kernel-dev@...lia.com,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [PATCH] tools/nolibc: Add stdbool.h to nolibc includes

Sep 25, 2025 16:37:45 André Almeida <andrealmeid@...lia.com>:

> Hi Mark,
>
> Em 25/09/2025 11:24, Mark Brown escreveu:
>> On Thu, Sep 25, 2025 at 11:14:23AM -0300, André Almeida wrote:
>>> Add stdbool.h to the list of nolibc.h includes, otherwise tests compiled
>>> with -nostdlib will fail with "error: unknown type name 'bool'", even if
>>> a nolibc stdbool implementation is available at tools/include/nolibc/.
>>>
>>> Reported-by: Mark Brown <broonie@...nel.org>
>>> Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
>>> Signed-off-by: André Almeida <andrealmeid@...lia.com>
>> Fixes: f2662ec26b26 ("selftests: kselftest: Create ksft_print_dbg_msg()")
>> ---
>>>   tools/include/nolibc/nolibc.h | 1 +
>>>   1 file changed, 1 insertion(+)
>> --- a/tools/include/nolibc/nolibc.h
>>> +++ b/tools/include/nolibc/nolibc.h
>>> @@ -116,6 +116,7 @@
>>>   #include "sched.h"
>>>   #include "signal.h"
>>>   #include "unistd.h"
>>> +#include "stdbool.h"
>>>   #include "stdio.h"
>>>   #include "stdlib.h"
>>>   #include "string.h"
>> It's not 100% clear to me that we should add this to the nolibc
>> includes given that nolibc itself does not rely on or offer stdbool -
>> I was going to send something out adjusting kselftest.h to unguard the
>> include there.
>
> If we don't include stdbool.h here, it looks like tools/include/nolibc/stdbool.h cannot be used by any test, and unguarding <stdbool.h> would defeat the purpose of using -nolibc?

It can still be used through '#include <stdbool.h>'.
But we support both ways of using nolibc, so this is a valid bugfix and I will apply it.

On the other hand removing the guard in kselftest.h would be nice too,
the code will look idiomatic.
It could trigger issues for programs that do not have tools/include/nolibc/ in their include path.
But Mark should be able to fund those.
I removed the guards in kselftest_harness.h before and that didn't lead to issues.

> I'm also not 100% sure as well, lets see if Thomas or Willy can shine a light here.