Michal/erts/fix-handling-of-short-paths-on-windows/OTP-19690 #9996
Conversation
CT Test Results 3 files 142 suites 49m 34s ⏱️ Results for commit b554434. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
Mikaka27
force-pushed
the
michal/erts/handle-windows-short-paths/OTP-19690
branch
6 times, most recently
from
60594a2 to
0faeb5e
Compare
Mikaka27
force-pushed
the
michal/erts/handle-windows-short-paths/OTP-19690
branch
from
0faeb5e to
1cf0dba
Compare
erts/etc/win32/erl.c
Outdated
|
|
||
| /* Chop of base name*/ | ||
| for (p = dir+wcslen(dir)-1 ;p >= dir && *p != L'\\'; --p) | ||
| ; | ||
| *p =L'\0'; | ||
| p--; | ||
|
|
||
| length = GetLongPathNameW(dir, NULL, 0); |
There was a problem hiding this comment.
We can get rid of _wcsdup(erlpath); if we chop off the base name after getting the long path name, saving us from having to free(dir) everywhere.
There was a problem hiding this comment.
I tried that, but here erlpath contains a path to file that can not exist (the erl.ini file), and in that case GetLongPathNameW will fail, if you ask it to convert possibly short path to long path of file/directory that does not exist, as pointed here:
If the function fails for any other reason, such as if the file does not exist, the return value is zero.
That's why I first chop of base name, and only then do the conversion.
erts/etc/win32/erl.c
Outdated
| free(dir); | ||
| error("Cannot find erlexec.dll"); | ||
| } | ||
| long_dir = (wchar_t *) malloc(length * sizeof(wchar_t)); |
There was a problem hiding this comment.
length does not include the null terminator.
| long_dir = (wchar_t *) malloc(length * sizeof(wchar_t)); | |
| long_dir = (wchar_t *) malloc((length + 1) * sizeof(wchar_t)); |
There was a problem hiding this comment.
I think it does include it, here it says:
If the lpBuffer buffer is too small to contain the path, the return value is the size, in TCHARs, of the buffer that is required to hold the path and the terminating null character.
Doesn't it mean that space for null is included in the return we get?
There was a problem hiding this comment.
I've changed that to make it more clear, hopefully now it's ok.
Mikaka27
force-pushed
the
michal/erts/handle-windows-short-paths/OTP-19690
branch
from
1cf0dba to
b554434
Compare
No description provided.