This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Fix usage of MAX_PATH in posixmodule.c
Type: Stage:
Components: Windows Versions: Python 3.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: python-dev, tim.golden, vstinner
Priority: normal Keywords: patch

Created on 2013-11-17 23:45 by vstinner, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
win_max_path.patch vstinner, 2013-11-17 23:45 review
Messages (5)
msg203231 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-17 23:45
The length of a path is not always correctly handled in posixmodule.c, the worst case is posix__getvolumepathname() which pass a length two times smaller than the buffer (GetVolumePathNameW() expects a number of WCHAR characters, not a number of bytes).

MAX_PATH includes the final null character, so no need to write MAX_PATH+1, especially when the function supports path longer than MAX_PATH-1 wide characters by allocating a larget buffer.
Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)"

Attached patch fixes usage of MAX_PATH in posixmodule.c.
msg203232 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-17 23:52

-    char outbuf[MAX_PATH*2];
+    char outbuf[MAX_PATH];
-        wchar_t woutbuf[MAX_PATH*2], *woutbufp = woutbuf;
+        wchar_t woutbuf[MAX_PATH], *woutbufp = woutbuf;

I don't know what "*2" was used here, probably a mistake with sizeof(wchar_t)=2? (try to allocate bytes, where the length is a number of wide characters)

posix__getvolumepathname() is new in Python 3.4, so not need to backport its fix.


     length = PyBytes_GET_SIZE(bytes);
 #ifdef MS_WINDOWS
-    if (length > MAX_PATH) {
+    if (length > MAX_PATH-1) {
         FORMAT_EXCEPTION(PyExc_ValueError, "%s too long for Windows");
         return 0;

I don't know if this fix should be backported to Python 3.3.
msg203240 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-18 01:10
Oh, I forgot to mention that my initial concern was the following warning:

  ..\Modules\posixmodule.c(4057): warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data [C:\\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj]

bufsize (Py_ssize_t) is passed to GetVolumePathNameW() which expected a DWORD. An OverflowError must be raised if bufsize is larger than DWORD_MAX (the constant is defined in Modules/_winapi.c, not in posixmodule.c).

But I prefer to fix the warning after this issue.
msg203407 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-11-19 18:23
Fine with your volumepathname patch. The core of the code was contributed and I didn't check it too carefully as it clearly worked. (For some definition of "worked").
msg204253 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-11-24 18:23
New changeset b3eb42a657a3 by Victor Stinner in branch 'default':
Issue #19636: Fix posix__getvolumepathname(), raise an OverflowError if

New changeset 46aecfc5e374 by Victor Stinner in branch 'default':
Issue #19636: Fix usage of MAX_PATH in posixmodule.c
Date User Action Args
2022-04-11 14:57:53adminsetgithub: 63835
2013-12-12 23:45:14vstinnersetstatus: open -> closed
resolution: fixed
versions: + Python 3.4
2013-11-24 18:23:52python-devsetnosy: + python-dev
messages: + msg204253
2013-11-19 18:23:36tim.goldensetmessages: + msg203407
2013-11-18 01:10:37vstinnersetmessages: + msg203240
2013-11-17 23:52:22vstinnersetnosy: + tim.golden
2013-11-17 23:52:11vstinnersetmessages: + msg203232
components: + Windows
2013-11-17 23:45:50vstinnercreate