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 --]
next prev parent 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®