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 |
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
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.
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 --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);
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(-)