uClibc's non-syscall getcwd() implementation uses the buffer provided by the application as working space.  However, there are two cases where the algorithm needs more working space to determine a directory name, than to store the result.

The more common case is when the directory being searched-for has a sibling file with a longer name.  uClibc will try to stat the sibling file, and will give up if that file's full filename will not fit in the buffer.

Another case, rarely seen in practice, is if the filename has many components that are single characters (eg: "/a/a/a/a/a/a").  In this case, the "./../../.." strings used during the first part of the search can run out of space.

This causes test failures in coreutils/gnulib -- which demands that getcwd() always work if there is enough buffer for the result.

Attached is a patch that addresses these two issues.  

The sibling file problem is addressed by assuming that any too-long file isn't the searched-for directory, and then returning ERANGE if the desired inode hasn't been found after reaching the end of the parent directory.

The a/a/a/a problem is resolved by a second search using a temporary buffer that is just large enough.