[Bug 3871] New: non-syscall getcwd() often fails with minimum buffer
bugzilla at busybox.net
bugzilla at busybox.net
Fri Jun 17 13:15:00 UTC 2011
https://bugs.busybox.net/show_bug.cgi?id=3871
Summary: non-syscall getcwd() often fails with minimum buffer
Product: uClibc
Version: 0.9.32
Platform: PC
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P5
Component: Other
AssignedTo: unassigned at uclibc.org
ReportedBy: michael at talamasca.ocis.net
CC: uclibc-cvs at uclibc.org
Estimated Hours: 0.0
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.
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the uClibc-cvs
mailing list