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

[Alejandro Colomar]

Hi Zack, Paul,

On Sun, Sep 14, 2025 at 11:19:05AM -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.

I don't think that's important.  The problem is whether the committee
would standardize something incompatible with this.  If the committee
standardizes the function, we could always implement it then, as long as
it has compatible semantics.

What I'm convinced is that the committee wouldn't standardize anything
incompatible with this; that is, something that would break code using
this API.  Regarding that, it's safe to do whatever we want here.

> > 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.

Yep, that's a possibility.

Would it be okay to provide the initial implementation as a macro, and
then improve them to be proper functions afterwards?  This makes the
initial patch simpler.

Or do you prefer having it directly as a function?


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
-------------- 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/20250914/3da9a6a2/attachment-0001.sig>