$ 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.