Eryk Sun <eryk...@gmail.com> added the comment:

> Any comments, questions or more feedback on the PR?

I commented on the PR that I'm concerned that ctypes.CDLL will no longer open a 
path with slashes in it (e.g. CDLL("./spam.dll") or CDLL("eggs/spam.dll")) 
relative to the working directory, and may accidentally match another directory 
in the search path. In POSIX, a path with a slash in it is always relative to 
the working directory and never searched for. In Windows, particularly for the 
loader, all relative paths are always searched for. This works with the current 
LoadLibraryW call, with minimal risk of name collisions, because only the 
application directory and system directories are checked before the working 
directory, which is checked before searching PATH. I suggest that with the 
change to use LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, ctypes should first resolve 
such a path by calling GetFullPathNameW, as is suggested in the Windows docs.

I also had suggested documenting and exposing a subset of the loader flags for 
use with the CDLL `mode` parameter, which is currently unused in Windows. This 
would make it convenient for a user to include the flag 
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR when the DLL path is fully qualified. However, 
that was deemed too peripheral to be worth the extra effort of supporting and 
documenting the parameter and adding the required tests, which is 
understandable. This can maybe be addressed in another issue, if the need 
arises. That said, it would be nice to provide parity with C extension modules 
here, which are always loaded with the latter flag. If given a fully-qualified 
path, or a relative path with slashes in it that's resolved via 
GetFullPathNameW, _ctypes.LoadLibrary could automatically include the 
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to