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 <rep...@bugs.python.org> <http://bugs.python.org/issue19636> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
