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

[Alejandro Colomar]

Hi Adhemerval, Paul,

On Tue, Sep 16, 2025 at 10:44:24AM -0300, Adhemerval Zanella Netto wrote:
> 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,

Sure; we can start with gnulib.  Paul, would you mind starting in
gnulib?

> so we can check whether other projects will be willing to start 
> using these functions and if they are truly useful.

If you do a Debian code search, there are many projects using functions
similar to this (either with the same name, or a different one).  Even
glibc defines some macros in some internal files for this.  Even for
internal uses of glibc, I think it would be already worth it.  (It
allows chopping many LoC in glibc already.)

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


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/20250916/6713098a/attachment-0001.sig>