mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®