homepage

On some Windows compilers, the constant PATH_MAX may already be defined, which will cause compile errors on non-MSVC compilers (notably Open Watcom and MinGW). Rather than assume it is not available and define it in all "#ifdef MS_WINDOWS" cases, it should first be checked for existence.
This patch adds said check to Modules/main.c and Python/pythonrun.c. This patch should not affect any existing platforms (including MSVC builds).

The patch is simple and looks safe. I'm in favor of applying it on Python 3.3 and 3.4. (Python 2.7 is not affect.)
@Larry: ok for Python 3.4?

Let's be a little smarter. PATH_MAX isn't used anymore. Just remove the #defines entirely.

Here's an additional patch removing PATH_MAX from Modules/main.c and Python/pythonrun.c. This solution works fine for me.

> Let's be a little smarter. PATH_MAX isn't used anymore. Just remove the #defines entirely.
Oh I remember that I replaced PATH_MAX with MAXPATHLEN or maybe something else when I tried to fix Python compilation issue on our IRIX buildbot :-)
remove_path_max.default.patch looks good to me. Larry: can it be applied on Python 3.4?
path_max.default.patch is still needed for Python 3.3.

I found it:
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.

Jeffrey: Which compilers specifically?
It's probably not MSVC, hence it's not a "supported" compiler, and IMO shouldn't go in after the release candidate for 3.4.

PATH_MAX is defined in both Open Watcom and MinGW's GCC toolchain. Neither is a "supported" compiler, I suppose. I hadn't meant to suggest that it be included in 3.4's release candidate, only that the problem exists on current versions.

Assuming you keep an eye on the buildbots, this has my permission to go in.
Martin: While we don't officially support those compilers, I don't see the harm of removing unused #defines, so I'm willing to accept it for rc2.

Was this ever accepted?

Reopening. I still don't understand the issue for 3.4, especially in the light of #21274 

What's to understand? Some compilers, particularly MinGW and Open Watcom, already define a PATH_MAX macro on Windows, and it's not necessarily the same as Python's redefinition of it, possibly causing a compiler error. That's all.
Given the time frame that this bug has existed (9 months!?!) and its trivial fix, which would involve adding an "#ifndef PATH_MAX" right before its declaration, I think "won't fix" is an appropriate resolution.
Leave it open or don't, it makes little difference to me as I'm no longer interested.

New changeset 6aaa0aab1e93 by Victor Stinner in branch 'default':
Issue #20597: Remove unused definition of PATH_MAX on Windows, MAXPATHLEN is
https://hg.python.org/cpython/rev/6aaa0aab1e93 

New changeset d6fb87972dee by Victor Stinner in branch 'default':
Issue #20597, #21274: Remove unused definition of PATH_MAX on GNU/Hurd,
https://hg.python.org/cpython/rev/d6fb87972dee 

> Reopening. I still don't understand the issue for 3.4, especially in the light of #21274
In Python 3.5, PATH_MAX is no more used in Modules/main.c nor Python/pythonrun.c. I removed the "#define PATH_MAX ..." on Windows on Hurd.
This issue is about supporting OpenWatcom which is not officially supported to compile Python on Windows, so I don't want to change Python 2.7 nor 3.4. If anyone disagree, please complain :-)
PATH_MAX is still used in posixmodule.c, but it looks to work on all platforms:
#ifndef MAXPATHLEN
#if defined(PATH_MAX) && PATH_MAX > 1024
#define MAXPATHLEN PATH_MAX
#else
#define MAXPATHLEN 1024
#endif
#endif /* MAXPATHLEN */
I'm now closing this issue.