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

[Adhemerval Zanella Netto]

On 15/09/25 16:00, Alejandro Colomar wrote:
> Hi Paul,
> 
> On Mon, Sep 15, 2025 at 09:41:29AM -0700, Paul Eggert wrote:
>> On 2025-09-15 00:18, Alejandro Colomar wrote:
>>> I gave up on static inline because of that.  TBH, I'd like to avoid
>>> doing tricks where users have a hard time understanding what glibc is
>>> doing.  I have enough trouble reading glibc sources myself already.
>>
>> OK, if we want to keep things absolutely simple in the headers, then we
>> should not use inline.
>>
>> It's too bad that glibc never uses C99-or-later inline in its headers, due
>> to portability hassles and inertia, particularly since Gnulib has been doing
>> it for many years. But I suppose this can be put off still further into the
>> future.
> 
> I wonder if gcc would agree to remove GNU inline.  That would open the
> door for using C99 inline eventually in glibc.
> 
> Of course, there's a problem in glibc, as it currently uses GNU inline
> extensively.  I'm not entirely sure how a transition period would look
> like; but we should have a look at that.
> 
> I would volunteer to work on trying to improve this in glibc if there's
> interest.  I certainly want to be able to use the standard inline here
> some day.
> 
> Also, I could volunteer to remove a lot of obsolete code that's there to
> support ancient versions of GCC, as Zack showed recently (IIRC it was
> Zack).
> 

I am wondering if it would be better to first add a gnulib module that 
implements these functions, either as static inlines or through proper 
symbols, so we can check whether other projects will be willing to start 
using these functions and if they are truly useful. The reference paper 
only considers a single experience, so it would be beneficial to have an 
understanding of other projects before committing to this extension (since 
it essentially provides syntax sugar, rather than addressing a specific 
limitation).