PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX).

[tpn]

BPO	16442
Nosy	@loewis, @vstinner, @tpn

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tpn'
closed_at = None
created_at = <Date 2012-11-08.16:48:46.559>
labels = ['build']
title = 'PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX).'
updated_at = <Date 2014-05-22.21:41:42.949>
user = 'https://github.com/tpn'

bugs.python.org fields:

activity = <Date 2014-05-22.21:41:42.949>
actor = 'skrah'
assignee = 'trent'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2012-11-08.16:48:46.559>
creator = 'trent'
dependencies = []
files = []
hgrepos = []
issue_num = 16442
keywords = []
message_count = 5.0
messages = ['175183', '175449', '175453', '218547', '218550']
nosy_count = 3.0
nosy_names = ['loewis', 'vstinner', 'trent']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue16442'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

[tpn]

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

[loewis]

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.

[skrah]

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

[skrah]

The HP-UX issue is fixed. Are we leaving this open for IRIX?

[vstinner]

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 <victor.stinner@gmail.com>
date: Fri Nov 15 17:09:24 2013 +0100
files: Python/pythonrun.c
description:
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.