Title: PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX).
Type: compile error Stage: needs patch
Components: Build Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: trent Nosy List: loewis, trent, vstinner
Priority: normal Keywords:

Created on 2012-11-08 16:48 by trent, last changed 2014-05-22 21:41 by skrah.

Messages (5)
msg175183 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2012-11-08 16:48
Two immediate issues identified whilst trying to build on HP-UX and IRIX:

1.  Our source is wildly inconsistent with regards to using PATH_MAX versus MAXPATHLEN.

2.  The current logic in osdefs.h is insufficient for ensuring one or the other always has a value (complicated by issue 1 above).

Christian alluded to introducing a PY_PATH_MAX define, which I like.  So, my proposal is to fix the logic in osdefs.h so that it works on a wider range of platforms, with the end goal of defining PY_PATH_MAX, then replacing all occurrences of PATH_MAX|MAXPATHLEN in our tree with the new PY_PATH_MAX.

(It's worth mentioning that, technically, we shouldn't be using PATH_MAX or MAXPATHLEN.  We should be using pathconf(..., _PC_PATH_CONF) to determine the maximum length of the underlying filesystem at runtime and dynamically allocating buffers based on that value.

However, that's a huge, non-trivial change.  For another day.)
msg175449 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-11-12 15:01
I don't think that using pathconf is an important part of this issue. Instead, it is more important to deal with ENAMETOOLONG errors. To do so, we should get rid of all stack allocations of arrays with PATH_MAX/MAXPATHLEN size (also because they can consume quite a lot of stack).

I agree that it important to scope this issue. You need to determine whether you want it to be a bug fix or a cleanup action. If the issue is "fails to build on HP-UX", then all other aspects not relevant to this issue need to be left out, in particular the introduction of new symbolic constants.

If the objective is the code clean-up, all versions but 3.4 need to be left out.

IOW, -1 on systematic introduction of PY_PATH_MAX to 2.7, 3.2, and 3.3.
msg175453 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-11-12 15:26
#15835 has a patch specifically for HP-UX. Also see the link in
msg171068 for evidence that PATH_MAX is quite a mess on HP-UX.
msg218547 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-05-14 15:29
The HP-UX issue is fixed. Are we leaving this open for IRIX?
msg218550 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-05-14 15:34
> The HP-UX issue is fixed. Are we leaving this open for IRIX?

Python doesn't support IRIX. I tried to fix compilation issues on IRIX related to PATH_MAX, but there are more serious compilation issues (ex: in socketmodule.c for example if I remember correctly).

I suggest to close this issue.

changeset:   87113:159e51e5fc2c
branch:      3.3
parent:      87102:46fc4fb2c8c5
user:        Victor Stinner <>
date:        Fri Nov 15 17:09:24 2013 +0100
files:       Python/pythonrun.c
pythonrun.c: fix Py_GetPythonHome(), use Py_ARRAY_LENGTH() to get the size of
the env_home buffer, not PATH_MAX+1. env_home is declared using MAXPATHLEN+1,
and PATH_MAX is not declared on IRIX.
Date User Action Args
2014-05-22 21:41:42skrahsetnosy: - skrah
2014-05-14 15:34:21vstinnersetnosy: + vstinner
messages: + msg218550
2014-05-14 15:29:21skrahsetmessages: + msg218547
2012-11-12 15:26:09skrahsetnosy: + skrah
messages: + msg175453
2012-11-12 15:01:53loewissetnosy: + loewis
messages: + msg175449
2012-11-08 16:48:46trentcreate