[Top][All Lists]

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

Re: getcwd fixes for bugs in glibc, Solaris, OpenBSD, ...

From: Jim Meyering
Subject: Re: getcwd fixes for bugs in glibc, Solaris, OpenBSD, ...
Date: Sun, 28 Nov 2004 22:25:08 +0100

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.

reply via email to

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