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

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>> IMHO, getcwd needs two changes: use the link-copying approach if possible,
>> and resort to using the O(n) openat approach.
>
> How about if we use the system getcwd if it works, and fall back on
> our own code if the system getcwd has problems?  In the typical
> case, if the system getcwd succeeds, or fails for any reason other
> than ERANGE, ENAMETOOLONG or ENOENT, we can simply use its result.

Yes, that's what I prefer, too.

> Advantages of this approach: it's simpler and easier to maintain,
> since we needn't know about the multiple ways Linux systems use to
> support getcwd (system calls, symlinks, bugs, etc.)
>
> I see two disadvantages of this approach: (1) we'll still have
> performance problems on Linux systems with kernel bugs (since we can't
> trust their getcwd implementation at all -- autoconf will detect this
> for us), and (2) we'll do about double the work if the working

Your point is valid, but it's not double the work.  As my timings showed,
calling the failing linux/libc getcwd costs far less than ( < 1% of)
the replacement, for a worst-case, long, working directory name.

> directory is slightly longer than PATH_MAX.  But (1) is a dying
> problem (2.4.19 and 2.4.20 kernels only, as far as I know), and (2) is
> a rare one.