[issue13496] bisect module: Overflow at index computation
New submission from Daniel Sturm : The mid index computation in _bisectmodule.c in both internal_bisect_right and internal_bisect_left is done with: mid = (lo + hi) / 2; // all three variables Py_ssize_t which is susceptible to overflows for large arrays, which would lead to undefined behavior (and in practice almost certainly a crash with a negative index) The fix is trivial - mid = lo + (hi - lo) / 2; - but since I'm just starting to look into the code base I may be missing some undocumented assertions that guarantee this can't happen. -- components: Extension Modules messages: 148517 nosy: Voo priority: normal severity: normal status: open title: bisect module: Overflow at index computation type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue13496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13496] bisect module: Overflow at index computation
Daniel Sturm added the comment: TBH I saw this more as an opportunity to get used to the whole system, how to create a patch, etc. :) Should've made it clearer at the start that this is unlikely to ever be a problem, sorry (didn't see a way to set priority to low myself). If my math isn't completely off, the highest possible value here is hi + (hi - 1) so this only occurs if hi > (MAX_SSIZE_T + 1) / 2. So this would only work out if we had such an array containing only a handful different objects. And then that's me assuming that a list is actually a thin wrapper around an array of PyObject*. -- ___ Python tracker <http://bugs.python.org/issue13496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18199] No long filename support for Windows
New submission from Daniel Sturm:
Python at the moment does not handle paths with more than MAX_PATH characters
well under Windows.
With Windows 7 x64, Python 3.3 32bit, the attached file fails with:
Traceback (most recent call last):
File ".\filename_bug.py", line 4, in
os.makedirs(dir)
File "C:\Python33\lib\os.py", line 269, in makedirs
mkdir(name, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified:
'./aa
aa/b
bbb'
Same things apply to os.rmdir and probably other functions.
The problem is that in posixmodule.c:path_converter (which is used to get the
wchar_t* pathname that is expected by the Win32 API) we do have the following
check:
length = PyUnicode_GET_SIZE(unicode);
if (length > 32767) {
FORMAT_EXCEPTION(PyExc_ValueError, "%s too long for Windows");
Py_DECREF(unicode);
return 0;
}
wide = PyUnicode_AsUnicode(unicode);
but the documentation states:
"The Windows API has many functions that also have Unicode versions to permit
an extended-length path for a maximum total path length of 32,767 characters.
This type of path is composed of components separated by backslashes, each up
to the value returned in the lpMaximumComponentLength parameter of the
GetVolumeInformation function (this value is commonly 255 characters). To
specify an extended-length path, use the "\\?\" prefix. For example,
"\\?\D:\very long path"."
Source:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
The problem is that we never prepend "\\?\" to the pathname hence getting the
old MAX_PATH limit.
To fix this the easiest solution would be to change the unicode code path of
the function to always return an absolute path (relative paths are always
limited by MAX_PATH) with \\?\. For optimization we could only do this if the
path is longer than 248 (CreateDir has another interesting exception there..)
resp. MAX_CHAR characters.
--
components: Unicode, Windows
files: filename_bug.py
messages: 191033
nosy: Voo, ezio.melotti
priority: normal
severity: normal
status: open
title: No long filename support for Windows
Added file: http://bugs.python.org/file30563/filename_bug.py
___
Python tracker
<http://bugs.python.org/issue18199>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18199] No long filename support for Windows
Changes by Daniel Sturm : -- components: +IO type: -> behavior ___ Python tracker <http://bugs.python.org/issue18199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18199] No long filename support for Windows
Daniel Sturm added the comment: > In my opinion, it is a bug in Windows I don't think calling every complicated API a "bug" is useful. Is the Win32 API exceedingly annoying? I think everybody agrees on that, but imo it's better to fix this once in python itself and don't force all developers to think about those details. Fixing this in pathlib is better than not doing anything, although with the large amounts of code out there that use os, it'd be nice if we could fix it at the source (also since I assume pathlib internally is going to call the os module, it's still the same amount of work). If I provide unit tests for all the involved file system functions and fix the issues (more work than expected looking at the linked issues, but doesn't seem too hard), would such a patch have chances to be included? -- ___ Python tracker <http://bugs.python.org/issue18199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
