mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx+linux-hardening@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	 Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
	Daniel Scally <djrscally@gmail.com>,
	 Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	 Danilo Krummrich <dakr@kernel.org>,
	Johan Hovold <johan@kernel.org>,
	 Hans Verkuil <hverkuil@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	 Kees Cook <kees@kernel.org>, Andy Shevchenko <andy@kernel.org>,
	Len Brown <lenb@kernel.org>,  Rob Herring <robh@kernel.org>,
	Saravana Kannan <saravanak@kernel.org>,
	 Linus Walleij <linusw@kernel.org>,
	linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
	 linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	devicetree@vger.kernel.org,  linux-gpio@vger.kernel.org
Subject: Re: [PATCH 5/9] of: property: implement the .property_get_names() fwnode operation
Date: Tue, 10 Nov 2026 16:10:54 +0100	[thread overview]
Message-ID: <avMzoKHbsuMcZpW2@devuan> (raw)
In-Reply-To: <avMBNUEL9_V7WnK-@devuan>

[-- Attachment #1: Type: text/plain, Size: 4265 bytes --]

> Date: 2026-11-10 12:35:22+0100
> From: Alejandro Colomar <alx+linux-hardening@kernel.org>
>
> > Date: 2026-11-10 12:10:57+0100
> > From: Alejandro Colomar <alx+linux-hardening@kernel.org>
> >
> > Hi Bart,
> > 
> > > Date: 2026-11-10 10:00:42+0100
> > > From: Bartosz Golaszewski <brgl@kernel.org>
> > >
> > [...]
> > > > > > > +		names[i] = kstrdup(prop->name, GFP_KERNEL);
> > > > > > 
> > > > > > Can property be statically defined somewhere? We might want to also optimize
> > > > > > these duplications with const variant (here or elsewhere, for fwnode generic
> > > > > > path, I believe).
> > > > > 
> > > > > Please rephrase because I'm not quite following what you're saying.
> > > > 
> > > > Can prop->name come from something that is declared as
> > > > 
> > > > static const ... foo = {
> > > > 	... .name = "bar";
> > > > };
> > > >
> > > 
> > > You can't know it for every instance of struct fwnode_handle, so the
> > > answer is: no.
> > > 
> > > PS: is there a way of using match_string() with non-const data?
> > 
> > Given the definition here:
> > 
> > 	$ grepc match_string .
> > 	./include/linux/string.h:int match_string(const char * const *array, size_t n, const char *string);
> > 	./lib/string_helpers.c:int match_string(const char * const *array, size_t n, const char *string)
> > 	{
> > 		int index;
> > 		const char *item;
> > 
> > 		for (index = 0; index < n; index++) {
> > 			item = array[index];
> > 			if (!item)
> > 				break;
> > 			if (!strcmp(item, string))
> > 				return index;
> > 		}
> > 
> > 		return -EINVAL;
> > 	}
> > 
> > You should be able to call it with a cast.  It's dangerous, but
> > technically it works.  I'm not encouraging it, though.  :)
> > 
> > 	char **strings;
> > 
> > 	...
> > 
> > 	i = match_string((const char *const *) strings, n, "foo");
> > 
> > This is a historic problem in C, which was solved in C++.
> 
> BTW, self-correction:  it is solved for char *const *, but char** is not
> convertible to const char *const *, neither in C++ nor in future C.

Self-correction of the self-correction: char ** will also be convertible
to const char *const *.  I was confused during a short moment, it seems.

	alx@devuan:~/tmp$ cat const.c 
	#include <stddef.h>

	int
	main(void)
	{
		const char *const *ccp = NULL;
		char **p;

		ccp = p;
	}
	alx@devuan:~/tmp$ cat const.c | gcc -x c++ -
	alx@devuan:~/tmp$ 


Cheers,
Alex

> 
> 
> Cheers,
> Alex
> 
> >  I have
> > a proposal paper for the C Committee for solving it as in C++:
> > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3987.htm>
> > 
> > This paper will be discussed (and probably voted in) in the next meeting
> > of the committee (which happens next week), so there's a chance that
> > this will be solved for C2y, and thus the cast will no longer be
> > necessary.
> > 
> > The history of why this is not allowed in C but is in C++ is, as far as
> > I've been told, the following:
> > 
> > Back before C and C++ were standardized, C++ invented const, with rules
> > slightly more allowing than what they are now.  This was going to be
> > standardized first in C89.  But very close to the release of C89, they
> > realized about the danger of converting a const char** to a char**
> > implicitly.  They were so close to the release, that they opted for the
> > safest approach: disallow any non-trivial conversions.
> > 
> > Later, while standardizing C++98, they realized we could allow a few
> > more conversions safely, and so they did.
> > 
> > C could have taken advantage of that, and pick C++ rules in C99 or C11,
> > but for some reason, nobody proposed that.  I'm proposing it now.  :)
> > 
> > We've already discussed this proposal informally within the committee
> > for some a year and a half, and there seems to be consensus that we want
> > it.  We're only being careful about the specific language.  But I think
> > I finally got it, and it will go in next week.
> > 
> > 
> > Have a lovely day!
> > Alex
> > 
> > > 
> > > Bart
> > > 
> > 
> > -- 
> > <https://www.alejandro-colomar.es>
> 
> 
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-11-10 15:11 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 14:03 [PATCH 0/9] gpio: make gpiolib-shared more fwnode-centric Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 1/9] device property: fix fwnode_name_eq() for empty node names Bartosz Golaszewski
2026-11-05 10:00   ` Sakari Ailus
2026-11-05 11:12   ` Alejandro Colomar
2026-11-04 14:03 ` [PATCH 2/9] lib: string_helpers: implement a CLASS() for string arrays Bartosz Golaszewski
2026-11-04 21:07   ` Andy Shevchenko
2026-11-04 14:03 ` [PATCH 3/9] fwnode: define the property_get_names() operation Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 4/9] device property: provide fwnode_property_get_names() Bartosz Golaszewski
2026-11-04 21:17   ` Andy Shevchenko
2026-11-09 11:16     ` Bartosz Golaszewski
2026-11-09 12:29       ` Alejandro Colomar
2026-11-09 12:59         ` Bartosz Golaszewski
2026-11-09 14:30           ` Alejandro Colomar
2026-11-09 14:53             ` Bartosz Golaszewski
2026-11-09 11:19     ` Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 5/9] of: property: implement the .property_get_names() fwnode operation Bartosz Golaszewski
2026-11-04 21:21   ` Andy Shevchenko
2026-11-09 13:07     ` Bartosz Golaszewski
2026-11-09 17:28       ` Andy Shevchenko
2026-11-10  9:00         ` Bartosz Golaszewski
2026-11-10  9:12           ` Andy Shevchenko
2026-11-10  9:50             ` Bartosz Golaszewski
2026-11-10 10:51               ` Andy Shevchenko
2026-11-10 11:33                 ` Alejandro Colomar
2026-11-10 14:06                 ` Bartosz Golaszewski
2026-11-10 14:23               ` Bartosz Golaszewski
2026-11-10 11:10           ` Alejandro Colomar
2026-11-10 11:13             ` Alejandro Colomar
2026-11-10 11:35             ` Alejandro Colomar
2026-11-10 15:10               ` Alejandro Colomar [this message]
2026-11-04 14:03 ` [PATCH 6/9] fwnode: define the count_references() " Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 7/9] device property: provide fwnode_property_count_references() Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 8/9] of: property: implement the count_references() fwnode operation Bartosz Golaszewski
2026-11-04 15:33   ` Rob Herring
2026-11-04 14:03 ` [PATCH 9/9] gpio: shared: generalize most code to firmware nodes Bartosz Golaszewski
2026-11-04 21:33   ` Andy Shevchenko
2026-11-05  6:28   ` kernel test robot
2026-11-05  7:34   ` kernel test robot

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=avMzoKHbsuMcZpW2@devuan \
    --to=alx+linux-hardening@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy@kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=brgl@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hverkuil@kernel.org \
    --cc=johan@kernel.org \
    --cc=kees@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lenb@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=saravanak@kernel.org \
    /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®