[Top][All Lists]

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

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

From: Jim Meyering
Subject: Re: [bug-gnulib] new modules chdir-long, openat; also, save-cwd improvements
Date: Wed, 19 Jan 2005 20:23:14 +0100

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.

reply via email to

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