From: Alejandro Colomar <alx+linux-hardening@kernel.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Alejandro Colomar <alx@kernel.org>,
linux-hardening@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
"Maciej W. Rozycki" <macro@orcam.me.uk>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andreas Schwab <schwab@linux-m68k.org>,
Andy Shevchenko <andy@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Daniel Scally <djrscally@gmail.com>,
Danilo Krummrich <dakr@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Joe Perches <joe@perches.com>, Johan Hovold <johan@kernel.org>,
Kees Cook <kees@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Len Brown <lenb@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linus Walleij <linusw@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Saravana Kannan <saravanak@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Tom Zanussi <zanussi@kernel.org>,
linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org
Subject: Re: [PATCH v3 3/5] stddef: Add const_cast()
Date: Wed, 11 Nov 2026 11:51:29 +0100 [thread overview]
Message-ID: <avRGnEBOpKhK8BMz@devuan> (raw)
In-Reply-To: <20261111102535.434c2eee@pumpkin>
[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]
Hi David,
> Date: 2026-11-11 10:25:35+0000
> From: David Laight <david.laight.linux@gmail.com>
>
> On Tue, 10 Nov 2026 16:33:40 +0100
> Alejandro Colomar <alx@kernel.org> wrote:
>
> > This macro serves to cast const away without risking unwanted
> > conversions due to mistakes in the cast.
> >
> > It's similar to C++'s const_cast(), but it is more restrictive: it can
> > only cast away 'const', and not arbitrary qualifiers.
> >
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > ---
> > include/linux/stddef.h | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/include/linux/stddef.h b/include/linux/stddef.h
> > index e1851c50c89b..d79a81406b78 100644
> > --- a/include/linux/stddef.h
> > +++ b/include/linux/stddef.h
> > @@ -194,4 +194,16 @@ enum {
> > #define TRAILING_OVERLAP(TYPE, NAME, FAM, MEMBERS) \
> > __TRAILING_OVERLAP(TYPE, NAME, FAM, /* no attrs */, MEMBERS)
> >
> > +/**
> > + * const_cast() - Drop const in the left-most derivation of a pointer
> > + *
> > + * @T: Type for the cast.
> > + * @p: Pointer to be casted.
> > + *
> > + * If @p is of type const @T, then it is casted to @T.
> > + * Otherwise, @p is returned without any casts.
> > + * This avoids mistakes that change anything other than 'const' in a cast.
> > + */
> > +#define const_cast(T, p) _Generic(p, const T: (T) (p), default: (p))
>
> Should it be de_const_cast(), or just de_const().
If we want to be explicit about it being for dropping, perhaps
drop_const() or cast_drop_const() feels more readable to me than
de_const(). I had been calling this const_cast() for following C++'s
name.
> It is a shame you need to specify the type,
In some cases we don't want to drop const; it's a "maybe drop const",
actually. Perhaps for this reason, cast_drop_const() might be
misleading, in that it tells you that it dropped const, but sometimes
it didn't. On the other hand, if you thougt you had dropped const and
haven't, you'll get build errors, so it's not a big problem.
The reason why we may want to not drop const is that since we do:
const_cast(CQChar_of(s) *, strprefix(s, pfx))
'CQChar_of() *' expands to either 'const char *' or 'char *', depending
on the qualification of 's'. In case it expands to 'const char *', we
want to retain const, and not drop it. The most accurate name would be
cast_at_most_drop_const_but_maybe_not(). :)
> but why not:
> _Generic(p, T: p, const T: (T)(p))
> so that you get a compile time error from the _Generic() if the type
> is wrong.
Thanks! I like that being more robust.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-11-11 10:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 15:33 [PATCH v3 0/5] Add strprefix() and fix a bug with it Alejandro Colomar
2026-11-10 15:33 ` [PATCH v3 1/5] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-10 15:47 ` Joe Perches
2026-11-10 16:14 ` Alejandro Colomar
2026-11-11 8:43 ` Steven Rostedt
2026-11-10 15:33 ` [PATCH v3 2/5] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-10 15:33 ` [PATCH v3 3/5] stddef: Add const_cast() Alejandro Colomar
2026-11-11 10:25 ` David Laight
2026-11-11 10:51 ` Alejandro Colomar [this message]
2026-11-10 15:33 ` [PATCH v3 4/5] string: Add [C]QChar_of() and QVoid_of() Alejandro Colomar
2026-11-10 15:33 ` [PATCH v3 5/5] string: Make strprefix() const-qualifier-generic Alejandro Colomar
2026-11-10 16:32 ` Joe Perches
2026-11-10 23:27 ` Alejandro Colomar
2026-11-11 10:28 ` David Laight
2026-11-11 10:59 ` Alejandro Colomar
2026-11-11 10:34 ` David Laight
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=avRGnEBOpKhK8BMz@devuan \
--to=alx+linux-hardening@kernel.org \
--cc=alx@kernel.org \
--cc=andy@kernel.org \
--cc=brgl@kernel.org \
--cc=dakr@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=joe@perches.com \
--cc=johan@kernel.org \
--cc=kees@kernel.org \
--cc=krzk@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=macro@orcam.me.uk \
--cc=namhyung@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sakari.ailus@linux.intel.com \
--cc=saravanak@kernel.org \
--cc=schwab@linux-m68k.org \
--cc=torvalds@linux-foundation.org \
--cc=zanussi@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®