Re: [bug-gnulib] new modules chdir-long, openat; also, save-cwd improvements

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> A few weeks ago I wrote rough replacements for fdopendir and fstatat so
>> that I could make getcwd.c more robust even on systems lacking openat
>> and those other two functions.
>
> Thanks.  This isn't trivial stuff....
>
>> [*] With these three replacement functions we might be able to remove
>> (or at least avoid using) getcwd's glibc-based O(N^2) code altogether
>> in favor of Paul's openat-based version.
>
> Wouldn't the openat-based version still be O(N^2) (and with a larger
> constant factor) on hosts where openat and fchdir aren't available in
> the standard library?

Yes, but do you know of even a single reasonable porting target
that lacks an fchdir function?  On the 20-30 different system types
for which I have coreutils-5.3.0 config.h files, *none* lack fchdir.

And once we have fchdir, (and even without openat et al), it's O(N).

>> For single-threaded applications, this change breaks the cycle:
>
> Ouch.  Perhaps we should alter the API to allow this to work even with
> multithreaded apps, or apps involving signals, etc.?  For example, we
> could add new functions __xgetcwd_internal() and __getcwd__internal
> that act just like xgetcwd and getcwd, except that they refuse to
> invoke a replacement openat.

Sounds like it's worth investigating.