Jim Meyering <[EMAIL PROTECTED]> wrote:
> Paul Eggert <[EMAIL PROTECTED]> wrote:
> ...
>> As a result of this patch, getcwd is limited only by available memory
>> on hosts like Solaris that support AT_FDCWD.
>
> But it has an unwelcome side effect: now, even on GNU libc systems,
> this replacement getcwd will end up opening "..", then "../..",
> etc. all the way up to "/", whereas the getcwd in libc.so just
> copies the symlink value from /proc/self/cwd. Of course, the
> /proc/self/cwd approach doesn't work for directory names that
> are longer than PATH_MAX.
>
> The combination of increased efficiency and no need for a file
> descriptor are compelling arguments to use a wrapper around the
> system-supplied getcwd, when possible. Or at least to try the
> /proc/self/cwd trick before resorting to the more expensive,
> robust code.
>
> What do you think?
BTW, a quick timing shows that gnulib's new getcwd
implementation also suffers from the O(n^2) effect.
I ran coreutils' pwd from a directory named (admittedly extreme)
/t/z/z/..../z of length 4200, two ways:
using xgetcwd compiled without change (hence, using the O(n^2) getcwd:
that took an average of 1.15 seconds.
using xgetcwd changed not to include getcwd.h (making it use the
/proc/self/cwd-link-copying getcwd from libc.so)
that took an average of 0.01 seconds.
IMHO, getcwd needs two changes: use the link-copying approach if possible,
and resort to using the O(n) openat approach.
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
