[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251126141711.GX1827@brightrain.aerifal.cx>
Date: Wed, 26 Nov 2025 09:17:11 -0500
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v2 1/1] include/string.h: Implement QChar wrappers
standardized in C23
On Wed, Nov 26, 2025 at 01:22:17PM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> On Tue, Nov 25, 2025 at 08:34:39PM -0500, Rich Felker wrote:
> > On Tue, Nov 25, 2025 at 10:49:29PM +0100, Alejandro Colomar wrote:
> [...]
> > > +# if __STDC_VERSION__ >= 202311L
> > > +# define strchrnul(s, ...) ((register __QCharof(s) *){ strchrnul(s, __VA_ARGS__)})
> > > +# define strcasestr(s, ...) ((register __QCharof(s) *){strcasestr(s, __VA_ARGS__)})
> > > +# endif
> > > #endif
> > >
> > > #ifdef __cplusplus
> > > --
> > > 2.51.0
> >
> > Could you explain a bit about your motivations for doing it this way?
> > Why are compound literals needed at all instead of just a value cast?
>
> Yup. I try to have 0 casts in my code. They silence several classes of
> diagnostics, and allow arbitrary conversions.
>
> For example, they could silence a bug in the prototype of strchr(3) if
> it accidentally returned an int*. Admittedly, <string.h> is so stable
> that it's not realistically going to have such bugs, so most of the
> issues it prevents are theoretical.
Yes, that is not an issue for libc.
> In my own projects, I don't trust myself so much, so I perform all
> return-value conversions through compound literals, which only allow
> implicit conversions.
Understandable, but it's not something we need to copy into musl.
> Alternatively, using a GNU extension, we can perform an lvalue
> conversion of the compound literal, which solves the problems caused by
> compound literals being lvalues:
>
> #define strchr(s, c) ({(__QCharof(s) *){strchr(s, c)};})
>
> This uses a statement expression ({...}), however. Is that okay?
> It depends on which features can be required in musl's headers.
No, we do not use statement-expressions.
> However, if you prefer it with a cast, I can change it. It's slightly
> less safe, but could be okay given how stable <string.h> should be.
It's absolutely safe; you can't define unsafety of one thing on the
basis of making another disallowed change that's world-breakingly
unsafe already.
> > Also, can't __Qcharof just be defined as something like
> > typeof(1?(s):"") without any fancy _Generic machinery?
>
> This wouldn't accept void*, and these functions should accept void*
> arguments.
I was thinking the ternary of char* and void* would produce char*, but
indeed I'm always wrong about that.
> I don't know if there might be a way to write it without _Generic(3),
> but I haven't found it.
Indeed, I can't think of any at the moment.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
