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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Wed Sep 3 11:26:12 GMT 2025



On 03/09/25 07:35, Alejandro Colomar wrote:
> 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 agree that we should wait for standardization, and Joseph was clear that
an implementation is not strictly required to move this proposal forward [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33337#c2


More information about the Libc-alpha mailing list