gh-134041: Avoid usage of unavailable windows path apis #134042
Conversation
|
@zooba I found some more cases that I was working around by explicitly linking the kernel32 lib (which shouldn't be done). It's the three done in here and the new |
Modules/_winapi.c
Outdated
| @@ -1672,6 +1677,10 @@ _winapi_GetShortPathName_impl(PyObject *module, LPCWSTR path) | |||
| PyErr_SetFromWindowsErr(0); | |||
| } | |||
| return result; | |||
| #else | |||
| PyErr_SetString(PyExc_OSError, "GetShortPathName unavailable on this platform"); | |||
There was a problem hiding this comment.
Your call here, but if you put the ifdef around the entire function definition and regenerate the clinic headers (should be python Tools\clinic\clinic.py Modules\_winapi.c unless someone finally moved the clinic.py script) then it should entirely omit the function when you build.
Or maybe it'd make sense just to return the original string again? I'm not sure where this function gets used, but in general, unconditional errors are harder to detect than a missing function, and are less convenient than sensible-but-technically-incorrect behaviours. This is an internal module, so we only really need to consider stdlib uses, though of course we want to avoid breaking existing third-party code as well.
There was a problem hiding this comment.
As far as I can tell we don't use this anywhere
IIUC, the game API functions are basically decided by what is requested, so I guess someone needed to set the state but not read it (which seems reasonable - you'd normally set the state to what you need rather than what's "best"). If they're needed by other internal functions, we might just need to get the Get one directly from the DLL (which is fine as long as we safely handle the case where we can't get it). If you prefer to just omit the entire function then that's fine by me. |
Would be fine with me as long as I know which dll to retrieve it from. In my original xbox change (https://github.com/python/cpython/pull/102256/files#diff-27e9033ac552bd8208213a2d5a0a294312e3918cd81c4da822ab32c382e392c4) we did the same for |
I think |
Docs say kernel32.dll. The path APIs are a bit special, as I don't think they were ever in kernel32 to begin with (they were advapi32 or shell32, IIRC), but really core stuff has always been accessible from kernel32. It might also be in an API set, but that shouldn't matter. This API isn't going to change at any rate we care about, and if the dynamic load is limited to the non-desktop partitions than devs have a much better chance of being able to manage breakage than regular users on desktop. |
|
Skipping NEWS because it's an internal module and won't affect normal releases. |
This doesn't contain a doc entry yet, since I wasn't sure about some of the changes yet:
Right now I have the following changes:
_winapi.GetLongPathName: I believe in the gaming partition you simply don't have short name support and so returning the path should be fine_winapi.GetShortPathName: throws an exception as unsupported_winapi.NeedCurrentDirectoryForExePath: I have absolutely no clue whether this should be True or False. Really I don't usually start different executables on these targets. Even if I do, I would always use a full path or have the exe placed next to my main executable. So really no clue whether this should: return True, False, throw an exception or be unavailable