[bug-gnulib] Re: getcwd fixes for bugs in glibc, Solaris, OpenBSD, ...

[Jim Meyering]

Jim Meyering <address@hidden> wrote:
> Paul Eggert <address@hidden> 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.