From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A5F177F39 for ; Sat, 23 May 2026 09:53:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779530027; cv=none; b=FXQawPFY8ZmtuvcGBu0icQdL6DZYZjNZNBFZHuZ1odWCWc29ALIS3+FJbsTWdSunsRh8NlArgxSPEAeqx3p/cLMdSfLvPC1qg1ix3x79ykY+7ab8hcvD/z0dGswFTKk9XjP3qYJUIOUB/Nfwsmp0AMAU/YWYyfn6Xcjll9K3VBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779530027; c=relaxed/simple; bh=pzvz670z0f04l0h6x3pcXOmGGYLPXv+uYNxpV4zh6a4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZLXe+FM6A/+noIiN3V94TORqKSxt+i7I5kgPYplHE+QluklBRHmFbS9Erwe2Jdi/HFPAJEvsMJKTOylIr5wIHjokMRewwpkM6ANsNfXYT1PkuRDiysCBjpnPLnWntjR4H0e5WDwFaccrz26RNmRcXyLvY58ygJFib4rIirS0SAM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kWlm5lPU; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kWlm5lPU" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-48a563e4ef7so61498555e9.0 for ; Sat, 23 May 2026 02:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779530025; x=1780134825; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=0sAM9fR8bcel4o+4UTgaB9j3NEf3J2cjFI9YHPOZgHQ=; b=kWlm5lPU4qfVofHfVIMUZZwEG6jlEVKgBh7WBooOIRfI0nIwhtdz3mEZfTI/Wejd65 flSkepWIgQq6LhwjxcNpHcVdnmiVQpqSbHSs6fLHo1jI/aVSBytlJomACvboHtDExFmJ ZrGn3jjlHtFVVHLxcPXu/M2+zCJhDUIpvJHioo/Wp/IPMW3wm2HHZn2qnPs+XI3HXb4I 06RRoNzG4FScDmyvPXiRGNhdUbZF3Z6ZQLak/59guyV5SDNUkAIGyUuyKt7oYL7EJCJV hdTJ9iRX9+1mELon2lHrV6ALrNY/XuXShCLHKo/ZSJMnNAXEf5vHXcrXhgCqGUGyXlir 5TVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779530025; x=1780134825; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0sAM9fR8bcel4o+4UTgaB9j3NEf3J2cjFI9YHPOZgHQ=; b=TxPyZE+waONOa0+EG1GQvkIE+NorFSBageTS6p2lpyzs/iWdYWpSifq8swwgv/MgSX 5Kg1WbnHNS5NBEa8uqvNOgLrZ1YbnZG4IHu0Q9seh0u1abQOwoFkhooGMs3SAMC8mcOF aXPbldVvYa+bjqHUXcndgXWzoA64u9+ORvNOf/RRFBJJfbBrYyxybHHiV/Z5sP0I4/sJ scYJjfNPPbMpojPABGaeYS9mVoxGfkggE+yRFBjFNloXSPL9tw5WBleM65AuSFYbAU6J Ob0roXMhSmNo/MBh1AcNycR4DxXX9c/9+3wd7dfweOir9oAKmEryZgqYl4muMUy3lQ5R 6fbg== X-Forwarded-Encrypted: i=1; AFNElJ/GIbtDjJTqVdzc2FtBCr2aKSSRmvP0tzYBp2Chl9NwJTu+NHfez43Cjb43d+limhu+PJwIO7A5L5qo+Ro=@vger.kernel.org X-Gm-Message-State: AOJu0YxFZLasYQbCx9kTneOrLDtug6YnLBGqwjVmvC11JbaUxJlIzQ7N sCPlKbbrFtkT6h+z64/twkAt/q3VmkHhbI4py5za7v8nAttcFGsVTr0v X-Gm-Gg: Acq92OFJLuiy1OwP88roGUJ3nU1CtELht9NChapVQn4O04mG0BP4ANHX/F/CLrfjC/S 6qvMrd/Ufxr4kcNPfEujNFAqz0XmG5hrfQ5pJhqI0camak/dJk8ztd5Z5SWv4nYmB0Te9w8d6fz bJtoN4lJESrIok/zK1W1Hz3D+AkAIZ0SfaxnTx8MkKeH+cF1KpV0HaDvv1HMlawRuAWprMm/Up6 FbS3pWrsg9ZH7JOcL9ThNKPd7EwgMqag6mJcIduDq8EH064vp6aGzrTBM2/M5qZY5/07Iyye4VT 0ViSC9bdfQ3Mav2sONSQnOpTbiS9av/6DQOi5VPNap1hYH9spiUsFnwxISoUALOUXSubEx3zwC8 7cnG8s/rjxQ1NRJPel9xuCZOW/NaENGZTokfPeEf7ID0i4r76ABeeQ5zMKSu7pViB8dmBXOy/Vm hoJcsl6IiuHBCDARyVzNKN8ynXsLfwoJBQRBTUGclca4K7BX7imsM21WN7YtnWbAxy X-Received: by 2002:a05:600c:3d96:b0:490:5429:1513 with SMTP id 5b1f17b1804b1-49054291bbamr17606205e9.6.1779530024338; Sat, 23 May 2026 02:53:44 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eb6d5e484sm10938730f8f.30.2026.05.23.02.53.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 May 2026 02:53:44 -0700 (PDT) Date: Sat, 23 May 2026 10:53:42 +0100 From: David Laight To: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= Cc: Willy Tarreau , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] selftests/nolibc: cast execve() argv string to character pointer Message-ID: <20260523105342.7c1def4b@pumpkin> In-Reply-To: <0cbdc16f-5882-4440-aadf-8ca5c7cd2c67@t-8ch.de> References: <20260521-nolibc-write-strings-v1-0-2debb3ad4142@weissschuh.net> <20260521-nolibc-write-strings-v1-2-2debb3ad4142@weissschuh.net> <20260521191558.6e62c6bc@pumpkin> <75da0d46-dabb-435f-b92a-3e2bf465b986@t-8ch.de> <20260522194807.4593150c@pumpkin> <0cbdc16f-5882-4440-aadf-8ca5c7cd2c67@t-8ch.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 22 May 2026 23:40:17 +0200 Thomas Wei=C3=9Fschuh wrote: > On 2026-05-22 19:48:07+0100, David Laight wrote: > > On Fri, 22 May 2026 16:39:58 +0200 > > Thomas Wei=C3=9Fschuh wrote: =20 > > > On 2026-05-21 19:15:58+0100, David Laight wrote: =20 > > > > On Thu, 21 May 2026 18:29:30 +0200 > > > > Thomas Wei=C3=9Fschuh wrote: > > > > =20 > > > > > The existing code would trigger a warning under -Wwrite-strings w= hich is > > > > > about to be enabled. execve() is specified as not modifying the a= rgv > > > > > array, but the exact semantics are not representable in the type = system. =20 > > > >=20 > > > > I suspect you'll have to fix it again to avoid 'casting away const'= . =20 > > >=20 > > > Where would this warning be coming from? Which compiler flags are nee= ded? > > > Afaik it is legal to cast away const. =20 > >=20 > > IIRC -Wcast-qual =20 >=20 > Yes that's it, thanks. >=20 > > 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. =20 >=20 > 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 =3D foo->n; g(); return foo->n =3D=3D n; } because it assumes that g() cannot change the contents of foo. >=20 > > > > Can you use something like (char[]){"/"} ? =20 > > >=20 > > > 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 requi= res > > > more memory. =20 > >=20 > > You can move a string from .rodata to .data easily enough. > > Doesn't change the memory footprint. =20 >=20 > 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[] =3D ""'. > 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