From: David Laight <david.laight.linux@gmail.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Willy Tarreau <w@1wt.eu>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer
Date: Fri, 22 May 2026 19:48:07 +0100 [thread overview]
Message-ID: <20260522194807.4593150c@pumpkin> (raw)
In-Reply-To: <75da0d46-dabb-435f-b92a-3e2bf465b986@t-8ch.de>
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
next prev parent reply other threads:[~2026-05-22 18:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 16:29 [PATCH 0/3] tools/nolibc: -Wwrite-strings compatibility Thomas Weißschuh
2026-05-21 16:29 ` [PATCH 1/3] tools/nolibc: cast default values of program_invocation_name Thomas Weißschuh
2026-05-21 16:29 ` [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer Thomas Weißschuh
2026-05-21 18:15 ` David Laight
2026-05-22 14:39 ` Thomas Weißschuh
2026-05-22 18:48 ` David Laight [this message]
2026-05-22 21:40 ` Thomas Weißschuh
2026-05-23 9:53 ` David Laight
2026-05-24 8:18 ` Thomas Weißschuh
2026-05-21 16:29 ` [PATCH 3/3] selftests/nolibc: test against -Wwrite-strings Thomas Weißschuh
2026-05-22 3:28 ` [PATCH 0/3] tools/nolibc: -Wwrite-strings compatibility Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260522194807.4593150c@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®