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

["Thomas Weißschuh" <linux@weissschuh.net>]

Sep 25, 2025 16:37:45 André Almeida <andrealmeid@igalia.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@kernel.org>
>>> Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
>>> Signed-off-by: André Almeida <andrealmeid@igalia.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.