bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Your gnulib patch


From: Jim Meyering
Subject: Re: Your gnulib patch
Date: Fri, 3 Jan 2020 15:30:58 -0800

On Fri, Jan 3, 2020 at 2:43 PM Cong Wang <address@hidden> wrote:
>
> On Wed, Jan 1, 2020 at 7:41 PM Jim Meyering <address@hidden> wrote:
> >
> > On Tue, Dec 24, 2019 at 11:13 AM Cong Wang <address@hidden> wrote:
> > > Hello, Jim
> > >
> > > We found your gnulib patch
> > > (http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=47cb657e)
> > > quite useful for us, as we encountered a same issue with a few million
> > > files under one directory.
> > >
> > > Is it possible for you to integrate the patch to glibc too? Our
> > > project doesn't use gnulib at all, so it would benefit more people if
> > > you could integrate it to glibc. :) I understand that would bring you
> > > more work, if I have your permission, I can help on that too. Please
> > > let me know how you would like to proceed.
> >
> > Hi Cong Wang,
> >
> > Thanks for your interest and the offer to contribute.
> >
> > If you'd like that functionality in glibc, note that it would have to
> > use different function names, because the gnulib version of fts uses a
> > different API (e.g., numerous struct changes were required to remove
> > limitations in the glibc version).
>
> I understand I need to add at least ->fts_dirp to FTSENT in glibc,
> but this seems fine as long as we only append to FTSENT? Users
> should only dereference those documented fields of this struct.
> Or am I still missing anything here?

There are other required new members, e.g., to avoid O(N^2) effects,
where N is the depth of the tree, and a 2^16 limit on the depth of a
tree.

Adding a new API to glibc is a big project. I suggest that you
reconsider using gnulib.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]