[RFC v4 2/4] string: Add streq,memeq,wcseq,wmemeq,strcaseeq[_l],wcscaseeq[_l] APIs

Alejandro Colomar alx@kernel.org
Fri Mar 6 23:03:35 GMT 2026


Hi Zack,

On 2025-09-14T11:19:05-0400, Zack Weinberg wrote:
> On Sun, Sep 14, 2025, at 11:04 AM, Paul Eggert wrote:
> > On 2025-09-13 23:01, Alejandro Colomar wrote:
> >> +#ifdef __USE_GNU
> >> +/* Compare N bytes of M1 and M2 for equality.  */
> >> +#define memeq(m1, m2, n)  ((__bool) !__memcmpeq(m1, m2, n))
> >> +#endif
> >
> > I doubt whether the standardization committee would bless this.
> > It's fine to have a macro, but there should also be a function
> 
> Reading this, I realized there's a practical reason why these need
> external function definitions, as well: people are going to want
> to use them as callbacks.

I've been thinking about this for quite some time, and I think I
disagree.

For example, functions like lfind(3) and lsearch(3) need a wrapper than
takes a pointer-to-a-pointer, and so streq(3) wouldn't be good as a
callback.

Also, the standard and glibc have both deprecated several functions (the
QChar and QVoid ones), so we have direction for not having functions
even if they might be useful as callbacks.  Admittedly, that's only for
the QChar and QVoid ones, because of type safety reasons, but that means
people will expect less functions in the future, and will understand
that some are only provided as macros.

As an example, gnulib has added a string API recently: strnul(3).  It is
only implemented as a macro.

I've also done global replacements of code by streq(3) and strnul(3) in
projects, and have yet not found a case where they'd be used as
callbacks.

So, can we please reconsider the possibility of providing it only as a
macro or static inline function?

And after the discussion some months ago about compatibility to very old
compilers, it might be simpler to start with a macro, and then consider
upgrading it to a static inline function later.

> 
> zw


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260307/0ed3fd4c/attachment.sig>


More information about the Libc-alpha mailing list