diff mbox series

[06/12] selftests/nolibc: avoid passing NULL to printf("%s")

Message ID 20240728-nolibc-llvm-v1-6-bc384269bc35@weissschuh.net (mailing list archive)
State Accepted
Commit f1a58f61d88642ae1e6e97e9d72d73bc70a93cb8
Headers show
Series tools/nolibc: improve LLVM/clang support | expand

Commit Message

Thomas Weißschuh July 28, 2024, 10:10 a.m. UTC
Clang on higher optimization levels detects that NULL is passed to
printf("%s") and warns about it.
Avoid the warning.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 tools/testing/selftests/nolibc/nolibc-test.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Willy Tarreau Aug. 3, 2024, 9:33 a.m. UTC | #1
On Sun, Jul 28, 2024 at 12:10:00PM +0200, Thomas Weißschuh wrote:
> Clang on higher optimization levels detects that NULL is passed to
> printf("%s") and warns about it.
> Avoid the warning.

I don't see why this would be a problem, we do explicitly check for
NULL in our printf implementation and print "(null)". Or maybe it is
upset due to the attribute(printf) ? I don't know what the standard
says regarding %s and NULL, though. If it says that NULL is forbidden
then I can understand the warning and your fix is indeed correct. In
any case it's not worth fighting with a compiler for nolibc-test, but
it's probably worth mentioning in the commit message that it warns
despite the check being already done.

Willy
Thomas Weißschuh Aug. 3, 2024, 6:29 p.m. UTC | #2
Aug 3, 2024 11:34:03 Willy Tarreau <w@1wt.eu>:

> On Sun, Jul 28, 2024 at 12:10:00PM +0200, Thomas Weißschuh wrote:
>> Clang on higher optimization levels detects that NULL is passed to
>> printf("%s") and warns about it.
>> Avoid the warning.
>
> I don't see why this would be a problem, we do explicitly check for
> NULL in our printf implementation and print "(null)". Or maybe it is
> upset due to the attribute(printf) ? I don't know what the standard
> says regarding %s and NULL, though. If it says that NULL is forbidden
> then I can understand the warning and your fix is indeed correct. In
> any case it's not worth fighting with a compiler for nolibc-test, but
> it's probably worth mentioning in the commit message that it warns
> despite the check being already done.

It's undefined as per POSIX.
I'll update the commit message.
Willy Tarreau Aug. 3, 2024, 6:33 p.m. UTC | #3
On Sat, Aug 03, 2024 at 08:29:14PM +0200, Thomas Weißschuh  wrote:
> Aug 3, 2024 11:34:03 Willy Tarreau <w@1wt.eu>:
> 
> > On Sun, Jul 28, 2024 at 12:10:00PM +0200, Thomas Weißschuh wrote:
> >> Clang on higher optimization levels detects that NULL is passed to
> >> printf("%s") and warns about it.
> >> Avoid the warning.
> >
> > I don't see why this would be a problem, we do explicitly check for
> > NULL in our printf implementation and print "(null)". Or maybe it is
> > upset due to the attribute(printf) ? I don't know what the standard
> > says regarding %s and NULL, though. If it says that NULL is forbidden
> > then I can understand the warning and your fix is indeed correct. In
> > any case it's not worth fighting with a compiler for nolibc-test, but
> > it's probably worth mentioning in the commit message that it warns
> > despite the check being already done.
> 
> It's undefined as per POSIX.
> I'll update the commit message.

OK, works for me!

Thanks,
Willy
diff mbox series

Patch

diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 093d0512f4c5..8cbb51dca0cd 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -542,7 +542,7 @@  int expect_strzr(const char *expr, int llen)
 {
 	int ret = 0;
 
-	llen += printf(" = <%s> ", expr);
+	llen += printf(" = <%s> ", expr ? expr : "(null)");
 	if (expr) {
 		ret = 1;
 		result(llen, FAIL);
@@ -561,7 +561,7 @@  int expect_strnz(const char *expr, int llen)
 {
 	int ret = 0;
 
-	llen += printf(" = <%s> ", expr);
+	llen += printf(" = <%s> ", expr ? expr : "(null)");
 	if (!expr) {
 		ret = 1;
 		result(llen, FAIL);