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

[Alejandro Colomar]

Hi Florian,

On Wed, Sep 03, 2025 at 12:18:25PM +0200, Florian Weimer wrote:
> * Alejandro Colomar:
> 
> > These inline functions serve the most common use case of the comparison
> > functions: test for equality.  They avoid the reversed return value that
> > confuses programmers.  Using these APIs will result in more readable
> > code, which in the end means safer code.
> >
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> 
> These names are already widely used in applications, so this will cause
> build failures.

Yeah, I guess that's a good thing.  They should check if libc provides
the API, and only provide it themselves if libc doesn't.  In the future,
they'll be able to drop their definitions, which means we'll allow
removing tons of existing user code.

As long as the breakage is non-silent, I think it's okay.
Plus, we already claim to reserve the str*() namespace.

Maybe we should provide these as macros, at least at first, which makes
it easier to check if libc provides them, with a simple #ifdef.

>  I don't think we should add this before these
> interfaces are standardized.

Joseph and I voted to standardize it, but for some reason, there are
people in the committee opposed to it, with reasons such as being
worried that it would be inconsistent that programs could use sometimes
strcmp(3) (mainly in old code) and sometimes streq() (in newly written
code).

I think we could convince the committee of standardizing this, but only
after important implementations have implemented it.

>  The standardization process could reverse
> the meaning of the return value (0 meaning equal, as in the existing
> comparison functions).

No; at least the committee seems to agree that if we want streq(), the
return value is the one I'm proposing here.  There was absolutely no
discussion about it.

>  Or pick different names, so we'd have cause
> trouble for developers for no reason.

Nope; the committee seemed relatively okay with the name.  There were
the usual concerns about breaking existing code, but then _Streq() was
voted against even more strongly, so streq() seems the least-hated name
by the committee.

And once important implementations provide it, there's less incentive
for the committee to significantly differ from it.


Have a lovely day!
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/20250903/00779939/attachment-0001.sig>