[Bug libc/12713] coreutils-8.12 "make check" thinks glibc-2.13's "getcwd()" is "buggy"

["eblake at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12713

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

--- Comment #1 from Eric Blake <eblake at redhat dot com> 2011-04-28 19:00:18 UTC ---
Glibc should consider borrowing code from gnulib's getcwd() implementation,
which is able to successfully determine working directories for several cases
where the getcwd(2) syscall fails and where glibc currently doesn't try any
harder:

http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/getcwd.c

At one point, that code was forked from glibc, but gnulib's version has added
additional improvements such as the use of openat() to get an answer in O(n)
rather than O(n^2) time.

Here's a sample program from gnulib that demonstrates a case of glibc giving up
too easily:

http://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-getcwd.c

You can demonstrate the glibc bug with that program (including building a
needed <config.h> required by its #includes) by checking out gnulib.git, and
running:

./gnulib-tool --with-tests --create-testdir --dir=path/to/dir getcwd
cd path/to/dir
./configure gl_cv_func_getcwd_path_max=yes
make check

Omit the gl_cv_func_getcwd_path_max assignment during ./configure to let gnulib
detect the limitation and use its fallback wrapper around glibc's getcwd.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.