[PATCH 0/3] tools/nolibc: -Wwrite-strings compatibility

[PATCH 0/3] tools/nolibc: -Wwrite-strings compatibility

[Thomas Weißschuh]

Make sure not to trigger -Wwrite-strings warnings.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Thomas Weißschuh (3):
      tools/nolibc: cast default values of program_invocation_name
      selftests/nolibc: cast execve() argv string to character pointer
      selftests/nolibc: test against -Wwrite-strings

 tools/include/nolibc/errno.h                    | 4 ++--
 tools/testing/selftests/nolibc/Makefile.include | 2 +-
 tools/testing/selftests/nolibc/nolibc-test.c    | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
---
base-commit: 136ca91411b0b637e862eb7b1cce2a56853edd17
change-id: 20260401-nolibc-write-strings-d7b2073917ff

Best regards,
--  
Thomas Weißschuh <linux@weissschuh.net>

[PATCH 1/3] tools/nolibc: cast default values of program_invocation_name

[Thomas Weißschuh]

With -Wwrite-strings the plain assignment triggers a warning as a
'const char *' is assigned to a 'char *', removing the const qualifier.

Casting the const away is fine, as there is no valid modification that
can be done to an empty string anyways.

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

diff --git a/tools/include/nolibc/errno.h b/tools/include/nolibc/errno.h
index bab83692ea1c..a2325596d550 100644
--- a/tools/include/nolibc/errno.h
+++ b/tools/include/nolibc/errno.h
@@ -15,8 +15,8 @@
 #ifndef NOLIBC_IGNORE_ERRNO
 #define SET_ERRNO(v) do { errno = (v); } while (0)
 int errno __attribute__((weak));
-char *program_invocation_name __attribute__((weak)) = "";
-char *program_invocation_short_name __attribute__((weak)) = "";
+char *program_invocation_name __attribute__((weak)) = (char *)"";
+char *program_invocation_short_name __attribute__((weak)) = (char *)"";
 #else
 #define SET_ERRNO(v) do { } while (0)
 #define program_invocation_name ""

-- 
2.54.0

[PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[Thomas Weißschuh]

The existing code would trigger a warning under -Wwrite-strings which is
about to be enabled. execve() is specified as not modifying the argv
array, but the exact semantics are not representable in the type system.
See the section "Rationale" in page linked below.

Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/exec.html
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 tools/testing/selftests/nolibc/nolibc-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index c3867cc570c6..9f8cb3672737 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -1533,7 +1533,7 @@ int run_syscall(int min, int max)
 		CASE_TEST(dup2_m1);           tmp = dup2(-1, 100); EXPECT_SYSER(1, tmp, -1, EBADF); if (tmp != -1) close(tmp); break;
 		CASE_TEST(dup3_0);            tmp = dup3(0, 100, 0);  EXPECT_SYSNE(1, tmp, -1); close(tmp); break;
 		CASE_TEST(dup3_m1);           tmp = dup3(-1, 100, 0); EXPECT_SYSER(1, tmp, -1, EBADF); if (tmp != -1) close(tmp); break;
-		CASE_TEST(execve_root);       EXPECT_SYSER(1, execve("/", (char*[]){ [0] = "/", [1] = NULL }, NULL), -1, EACCES); break;
+		CASE_TEST(execve_root);       EXPECT_SYSER(1, execve("/", (char*[]){ [0] = (char *)"/", [1] = NULL }, NULL), -1, EACCES); break;
 		CASE_TEST(fchdir_stdin);      EXPECT_SYSER(1, fchdir(STDIN_FILENO), -1, ENOTDIR); break;
 		CASE_TEST(fchdir_badfd);      EXPECT_SYSER(1, fchdir(-1), -1, EBADF); break;
 		CASE_TEST(file_stream);       EXPECT_SYSZR(1, test_file_stream()); break;

-- 
2.54.0

[PATCH 3/3] selftests/nolibc: test against -Wwrite-strings

[Thomas Weißschuh]

Users may use this warning when building their own applications.
Make sure that nolibc does not trigger any such warnings.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 tools/testing/selftests/nolibc/Makefile.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/nolibc/Makefile.include b/tools/testing/selftests/nolibc/Makefile.include
index 96fe2bc2191e..c30ca3a9ef14 100644
--- a/tools/testing/selftests/nolibc/Makefile.include
+++ b/tools/testing/selftests/nolibc/Makefile.include
@@ -6,7 +6,7 @@ _CFLAGS_STACKPROTECTOR ?= $(call try-run, \
 	$(__CFLAGS_STACKPROTECTOR))
 _CFLAGS_SANITIZER ?= $(call cc-option,-fsanitize=undefined -fsanitize-trap=all)
 CFLAGS_NOLIBC_TEST  ?= -Os -fno-ident -fno-asynchronous-unwind-tables -std=c89 \
-		-W -Wall -Wextra -Wundef \
+		-W -Wall -Wextra -Wundef -Wwrite-strings \
 		$(call cc-option,-fno-stack-protector) $(call cc-option,-Wmissing-prototypes) \
 		$(_CFLAGS_STACKPROTECTOR) $(_CFLAGS_SANITIZER)
 

-- 
2.54.0

Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[David Laight]

On Thu, 21 May 2026 18:29:30 +0200
Thomas Weißschuh <linux@weissschuh.net> wrote:

> The existing code would trigger a warning under -Wwrite-strings which is
> about to be enabled. execve() is specified as not modifying the argv
> array, but the exact semantics are not representable in the type system.

I suspect you'll have to fix it again to avoid 'casting away const'.
Can you use something like (char[]){"/"} ?

-- David

> See the section "Rationale" in page linked below.
> 
> Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/exec.html
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>  tools/testing/selftests/nolibc/nolibc-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> index c3867cc570c6..9f8cb3672737 100644
> --- a/tools/testing/selftests/nolibc/nolibc-test.c
> +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> @@ -1533,7 +1533,7 @@ int run_syscall(int min, int max)
>  		CASE_TEST(dup2_m1);           tmp = dup2(-1, 100); EXPECT_SYSER(1, tmp, -1, EBADF); if (tmp != -1) close(tmp); break;
>  		CASE_TEST(dup3_0);            tmp = dup3(0, 100, 0);  EXPECT_SYSNE(1, tmp, -1); close(tmp); break;
>  		CASE_TEST(dup3_m1);           tmp = dup3(-1, 100, 0); EXPECT_SYSER(1, tmp, -1, EBADF); if (tmp != -1) close(tmp); break;
> -		CASE_TEST(execve_root);       EXPECT_SYSER(1, execve("/", (char*[]){ [0] = "/", [1] = NULL }, NULL), -1, EACCES); break;
> +		CASE_TEST(execve_root);       EXPECT_SYSER(1, execve("/", (char*[]){ [0] = (char *)"/", [1] = NULL }, NULL), -1, EACCES); break;
>  		CASE_TEST(fchdir_stdin);      EXPECT_SYSER(1, fchdir(STDIN_FILENO), -1, ENOTDIR); break;
>  		CASE_TEST(fchdir_badfd);      EXPECT_SYSER(1, fchdir(-1), -1, EBADF); break;
>  		CASE_TEST(file_stream);       EXPECT_SYSZR(1, test_file_stream()); break;
> 

Re: [PATCH 0/3] tools/nolibc: -Wwrite-strings compatibility

[Willy Tarreau]

Hi Thomas,

On Thu, May 21, 2026 at 06:29:28PM +0200, Thomas Weißschuh wrote:
> Make sure not to trigger -Wwrite-strings warnings.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

Looks good, and it's pleasant to see that we can enable one extra warning
with so few changes.

Acked-by: Willy Tarreau <w@1wt.eu>

Thanks!
Willy

Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[Thomas Weißschuh]

On 2026-05-21 19:15:58+0100, David Laight wrote:
> On Thu, 21 May 2026 18:29:30 +0200
> Thomas Weißschuh <linux@weissschuh.net> wrote:
> 
> > The existing code would trigger a warning under -Wwrite-strings which is
> > about to be enabled. execve() is specified as not modifying the argv
> > array, but the exact semantics are not representable in the type system.
> 
> I suspect you'll have to fix it again to avoid 'casting away const'.

Where would this warning be coming from? Which compiler flags are needed?
Afaik it is legal to cast away const.

> Can you use something like (char[]){"/"} ?

That looks good. However if this issue is real we will also have it in
nolibc's errno.h. There I don't want to use this pattern, as it requires
more memory.

(...)


Thomas

Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[David Laight]

On Fri, 22 May 2026 16:39:58 +0200
Thomas Weißschuh <linux@weissschuh.net> wrote:

> On 2026-05-21 19:15:58+0100, David Laight wrote:
> > On Thu, 21 May 2026 18:29:30 +0200
> > Thomas Weißschuh <linux@weissschuh.net> wrote:
> >   
> > > The existing code would trigger a warning under -Wwrite-strings which is
> > > about to be enabled. execve() is specified as not modifying the argv
> > > array, but the exact semantics are not representable in the type system.  
> > 
> > I suspect you'll have to fix it again to avoid 'casting away const'.  
> 
> Where would this warning be coming from? Which compiler flags are needed?
> Afaik it is legal to cast away const.

IIRC -Wcast-qual
Lots of things are legal :-)
The problem with enabling -Wcast-qual (NetBSD's kernel does/did) it is makes
life annoying when you really do have to do it.
(From what I remember there weren't really that many.)
You sort of want an (unconst foo *) cast that won't generate a warning when
a simple (foo *) cast would.

> > Can you use something like (char[]){"/"} ?  
> 
> That looks good. However if this issue is real we will also have it in
> nolibc's errno.h. There I don't want to use this pattern, as it requires
> more memory.

You can move a string from .rodata to .data easily enough.
Doesn't change the memory footprint.

Not relevant for nolibc, but initialising a short string on stack
may well be faster than accessing the same string in .rodata because
of the missed caches miss (if you get what I mean).

-- David

> 
> (...)
> 
> 
> Thomas

Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[Thomas Weißschuh]

On 2026-05-22 19:48:07+0100, David Laight wrote:
> On Fri, 22 May 2026 16:39:58 +0200
> Thomas Weißschuh <linux@weissschuh.net> wrote:
> > On 2026-05-21 19:15:58+0100, David Laight wrote:
> > > On Thu, 21 May 2026 18:29:30 +0200
> > > Thomas Weißschuh <linux@weissschuh.net> wrote:
> > >   
> > > > The existing code would trigger a warning under -Wwrite-strings which is
> > > > about to be enabled. execve() is specified as not modifying the argv
> > > > array, but the exact semantics are not representable in the type system.  
> > > 
> > > I suspect you'll have to fix it again to avoid 'casting away const'.  
> > 
> > Where would this warning be coming from? Which compiler flags are needed?
> > Afaik it is legal to cast away const.
> 
> IIRC -Wcast-qual

Yes that's it, thanks.

> Lots of things are legal :-)
> The problem with enabling -Wcast-qual (NetBSD's kernel does/did) it is makes
> life annoying when you really do have to do it.
> (From what I remember there weren't really that many.)
> You sort of want an (unconst foo *) cast that won't generate a warning when
> a simple (foo *) cast would.

There seem to be a fair amount of standard C APIs which require such
casts, for example strstr(). Also the UAPI headers currently emit such
warnings. So I am not sure if it makes sense to try to get nolibc
compile with this warning.

> > > Can you use something like (char[]){"/"} ?  
> > 
> > That looks good. However if this issue is real we will also have it in
> > nolibc's errno.h. There I don't want to use this pattern, as it requires
> > more memory.
> 
> You can move a string from .rodata to .data easily enough.
> Doesn't change the memory footprint.

When using the proposed pattern in errno.h I get plus 4 bytes of .bss
usage for each variable. While it doesn't make a difference in the
binary, at runtime these bytes are quite wasted.
I didn't look closely at it yet, but the compiler could be reusing a
single empty string in .rodata for all different users, while the .data
one needs to be duplicated for each one.

So I think the current version, casting to (char *), is still the
best aproach for now.

> Not relevant for nolibc, but initialising a short string on stack
> may well be faster than accessing the same string in .rodata because
> of the missed caches miss (if you get what I mean).

Ack.


Thomas

Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[David Laight]

On Fri, 22 May 2026 23:40:17 +0200
Thomas Weißschuh <linux@weissschuh.net> wrote:

> On 2026-05-22 19:48:07+0100, David Laight wrote:
> > On Fri, 22 May 2026 16:39:58 +0200
> > Thomas Weißschuh <linux@weissschuh.net> wrote:  
> > > On 2026-05-21 19:15:58+0100, David Laight wrote:  
> > > > On Thu, 21 May 2026 18:29:30 +0200
> > > > Thomas Weißschuh <linux@weissschuh.net> wrote:
> > > >     
> > > > > The existing code would trigger a warning under -Wwrite-strings which is
> > > > > about to be enabled. execve() is specified as not modifying the argv
> > > > > array, but the exact semantics are not representable in the type system.    
> > > > 
> > > > I suspect you'll have to fix it again to avoid 'casting away const'.    
> > > 
> > > Where would this warning be coming from? Which compiler flags are needed?
> > > Afaik it is legal to cast away const.  
> > 
> > IIRC -Wcast-qual  
> 
> Yes that's it, thanks.
> 
> > Lots of things are legal :-)
> > The problem with enabling -Wcast-qual (NetBSD's kernel does/did) it is makes
> > life annoying when you really do have to do it.
> > (From what I remember there weren't really that many.)
> > You sort of want an (unconst foo *) cast that won't generate a warning when
> > a simple (foo *) cast would.  
> 
> There seem to be a fair amount of standard C APIs which require such
> casts, for example strstr(). Also the UAPI headers currently emit such
> warnings. So I am not sure if it makes sense to try to get nolibc
> compile with this warning.

It ought to be an aim :-)

Very recent headers use _Generic() so that the return type of strchr()
and strstr() is the same as the argument.
It should be possibly to get the linker to use the same symbol for both
so the code only exists once.

There is also the problem that 'const foo *' can either mean 'the data
area cannot be written to through this pointer' or 'the data area cannot
be written to at all'.
I've seen gcc assume the latter and then 'miscompile':
int f(const struct foo *foo)
{
	int n = foo->n;
	g();
	return foo->n == n;
}
because it assumes that g() cannot change the contents of foo.

> 
> > > > Can you use something like (char[]){"/"} ?    
> > > 
> > > That looks good.

Given that the exec() test does the same for argv[] (mostly to get
it all one one line) and object size doesn't really matter there
that one could be done that was - almost for consistency.

> > > However if this issue is real we will also have it in
> > > nolibc's errno.h. There I don't want to use this pattern, as it requires
> > > more memory.  
> > 
> > You can move a string from .rodata to .data easily enough.
> > Doesn't change the memory footprint.  
> 
> When using the proposed pattern in errno.h I get plus 4 bytes of .bss
> usage for each variable. While it doesn't make a difference in the
> binary, at runtime these bytes are quite wasted.
> I didn't look closely at it yet, but the compiler could be reusing a
> single empty string in .rodata for all different users, while the .data
> one needs to be duplicated for each one.

That will happen, and the linker might merge the string with another '\0'
in .rodata.str.1
You'd need to have a named 'char null[] = ""'.

> So I think the current version, casting to (char *), is still the
> best aproach for now.

Avoiding casting away const is hard.
ISTR that there are also oddities with volatile.

-- David

Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer

[Thomas Weißschuh]

On 2026-05-23 10:53:42+0100, David Laight wrote:
> On Fri, 22 May 2026 23:40:17 +0200
> Thomas Weißschuh <linux@weissschuh.net> wrote:
> 
> > On 2026-05-22 19:48:07+0100, David Laight wrote:
> > > On Fri, 22 May 2026 16:39:58 +0200
> > > Thomas Weißschuh <linux@weissschuh.net> wrote:  
> > > > On 2026-05-21 19:15:58+0100, David Laight wrote:  
> > > > > On Thu, 21 May 2026 18:29:30 +0200
> > > > > Thomas Weißschuh <linux@weissschuh.net> wrote:
> > > > >     
> > > > > > The existing code would trigger a warning under -Wwrite-strings which is
> > > > > > about to be enabled. execve() is specified as not modifying the argv
> > > > > > array, but the exact semantics are not representable in the type system.    
> > > > > 
> > > > > I suspect you'll have to fix it again to avoid 'casting away const'.    
> > > > 
> > > > Where would this warning be coming from? Which compiler flags are needed?
> > > > Afaik it is legal to cast away const.  
> > > 
> > > IIRC -Wcast-qual  
> > 
> > Yes that's it, thanks.
> > 
> > > Lots of things are legal :-)
> > > The problem with enabling -Wcast-qual (NetBSD's kernel does/did) it is makes
> > > life annoying when you really do have to do it.
> > > (From what I remember there weren't really that many.)
> > > You sort of want an (unconst foo *) cast that won't generate a warning when
> > > a simple (foo *) cast would.  
> > 
> > There seem to be a fair amount of standard C APIs which require such
> > casts, for example strstr(). Also the UAPI headers currently emit such
> > warnings. So I am not sure if it makes sense to try to get nolibc
> > compile with this warning.
> 
> It ought to be an aim :-)

Absolutely.

> Very recent headers use _Generic() so that the return type of strchr()
> and strstr() is the same as the argument.
> It should be possibly to get the linker to use the same symbol for both
> so the code only exists once.

_Generic() seems to work in GCC 4.9 and clang 3.0, even in C89 mode.
So we could indeed make use of it. IIRC there were some other casts
which would not be avoided with it. But still nice on its own.

(...)

> > > > > Can you use something like (char[]){"/"} ?    
> > > > 
> > > > That looks good.
> 
> Given that the exec() test does the same for argv[] (mostly to get
> it all one one line) and object size doesn't really matter there
> that one could be done that was - almost for consistency.

Ack, will do.

> > > > However if this issue is real we will also have it in
> > > > nolibc's errno.h. There I don't want to use this pattern, as it requires
> > > > more memory.  
> > > 
> > > You can move a string from .rodata to .data easily enough.
> > > Doesn't change the memory footprint.  
> > 
> > When using the proposed pattern in errno.h I get plus 4 bytes of .bss
> > usage for each variable. While it doesn't make a difference in the
> > binary, at runtime these bytes are quite wasted.
> > I didn't look closely at it yet, but the compiler could be reusing a
> > single empty string in .rodata for all different users, while the .data
> > one needs to be duplicated for each one.
> 
> That will happen, and the linker might merge the string with another '\0'
> in .rodata.str.1
> You'd need to have a named 'char null[] = ""'.

As long as there are no other users, it's still more memory for this
very edge case. Something to keep in mind though, if we need to add
such a shared variable for another usecase. With a better name though.
:-)

(...)


Thomas