[issue19636] Fix usage of MAX_PATH in posixmodule.c

STINNER Victor report at bugs.python.org
Mon Nov 18 00:45:50 CET 2013


New submission from STINNER Victor:

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.

http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
"
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.

----------
files: win_max_path.patch
keywords: patch
messages: 203231
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix usage of MAX_PATH in posixmodule.c
Added file: http://bugs.python.org/file32675/win_max_path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19636>
_______________________________________


More information about the Python-bugs-list mailing list