homepage

$ python -c "print len('`pwd`'); import os; print os.getcwd()"
1174
Traceback (most recent call last):
 File "<string>", line 1, in ?
OSError: [Errno 34] Numerical result out of range
$
The getcwd man page documents the ERANGE failure and suggests that the
calling application allocate a larger buffer and try again.

Why isn't the buffer length MAX_PATH anyway?

It should be MAX_PATH. All path related functions should use MAX_PATH as
buffer size, maybe even MAX_PATH+1

MAX_PATH is a compile time constant which, like FD_BITS for select(),
may be too small for the system you're ultimately running on.
Using that as default initial size is OK, but handling ERANGE is still a
very good idea.

This affects OS X too.
I'm attaching two patches - one uses malloc to build a bigger string if
the existing implementation returns ERANGE, and the other one uses
malloc from the start. This was done on the theory that stack memory
use would be better/more efficient. However, based on testing, there's
no real difference - 16.8usec vs. 17usec - on a rarely-used function.

Here's a patch to add a test that fails with Python 2.5 on OS X, but
passes with either of these patches.

Went for the malloc only patch. Just fixed a small detail (weird corner
case if malloc returned NULL first time, res will be unassigned).
The test could be better (no necessity of using a recursive function, it
could be done with a while), but it works.
Commited in r64452.

This bug occurred in posix_getcwd() and is being fixed. 
Should the following code in posix_getcwdu() also be fixed the same way?
posix_getcwdu(PyObject *self, PyObject *noargs)
{
	char buf[1026];
 ...
#if defined(PYOS_OS2) && defined(PYCC_GCC)
	res = _getcwd2(buf, sizeof buf);
#else
	res = getcwd(buf, sizeof buf);
#endif
 ...
}
In my opinion, the fixed length buf should be discarded and instead
allocate memory to buf as needed (as the fix code in posix_getcwd()),
since getcwd() does not have a maximum anymore.

Please open a new issue; and a patch is welcome.

Amaury,
Created issue 6817 with a patch.