This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: I'm unhappy about twalk_r
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 14 May 2019 16:50:27 -0300
- Subject: Re: I'm unhappy about twalk_r
- References: <xnimucdhgl.fsf@greed.delorie.com>
On 14/05/2019 15:22, DJ Delorie wrote:
>
> Florian Weimer <fweimer@redhat.com> writes:
>> Exposing this information using the VISIT argument seems wrong to me.
>
> I agree. It would be more useful if the binary-ness of the tree were
> *more* exposed, so the user could take advatage of the walk-order, but
> we don't expose it.
>
>> I think this is much more useful: It avoids pointless repeated calls to
>> ACTION, and it allows premature termination of the iteration.
>
> twalk() is defined by POSIX. If we have a *_r version of it, it should
> conform to the POSIX definition as closely as we can, despite these
> inefficiencies.
>
> Perhaps we could add a twalk_find_r() function that does something
> between twalk and tfind? Or twalk_sorted_r()? Or something else not
> called twalk_r()?
>
> Of course, that assumes that we have a need for a walk-no-find function
> that isn't already solved by either twalk or tfind.
>
So should we still provide a twalk_r or aim to just add a more sane
interface and work with POSIX to promote it?