Drop boost::scoped_array and simplify the code.
TCHAR should be defined as wchar_t if UNICODE is defined. So we can use .toStdWString().c_str() to get wchar_t C-style string.
Fix #13819
Drop boost::scoped_array and simplify the code.
TCHAR should be defined as wchar_t if UNICODE is defined. So we can use .toStdWString().c_str() to get wchar_t C-style string.
Fix #13819
Hope there is a way to see code that is before he force push.
Concept ACK
Thanks for removing Boost dependencies. Keep it coming! :-)
Any suggestion on how to test this?
This is Windows-only code, can be tested as same as #5793 (comment)
614 | @@ -625,7 +615,7 @@ bool SetStartOnSystemStartup(bool fAutoStart)
615 | #ifndef UNICODE
616 | psl->SetArguments(strArgs.toStdString().c_str());
617 | #else
Add a comment that UNICODE is only defined for Windows? (if that's the case)
Should the reference also be removed from test/lint/lint-includes.sh?
Tested that make still works on macOS.
Tested the gitian binary on a Windows 10 VM, by launching with bitcoin-qt -wallet=你好, assuming that was the problem? This leads to a crash, but that's also the case on master:
<img width="509" alt="schermafbeelding 2018-07-24 om 17 43 26" src="https://user-images.githubusercontent.com/10217/43150188-976eb0e8-8f69-11e8-9d97-861e005d9c7d.png">
I have a version from earlier this year where it leads to a slightly nicer crash: <img width="494" alt="schermafbeelding 2018-07-24 om 17 46 37" src="https://user-images.githubusercontent.com/10217/43150318-e859c01a-8f69-11e8-8dca-ac36aa8774f6.png">
(seems unrelated, so I made a ticket #13754)
bitcoin-qt -wallet=test works fine by the way, maybe that was all.
Update: Since the goal is to make it unicode compatible, just make it use wchar_t version of api explicitly.
554 |
555 | if (SUCCEEDED(hres))
556 | {
557 | // Get the current executable path
558 | - TCHAR pszExePath[MAX_PATH];
559 | - GetModuleFileName(nullptr, pszExePath, sizeof(pszExePath));
This is bug before, if TCHAR is wchar_t, then sizeof(pszExePath)= 2*MAX_PATH, which can result memory overflow.
Tested that make still works on macOS with 5d70ab0. I have no opinion on the code itself, other than it seems good to keep making progress here: https://github.com/bitcoin/bitcoin/projects/3#card-205363
Tested that for commit 6031f7f (master and this pull) I can launch regtest and testnet after re-login for a user with only ascii character in the name.
(See lower left of screenshot, Compare to #5793 (comment))

@MarcoFalke Can you test this again? Now it should fix #13819.
Now it fails for commit d41914b (master and this pull) that it can not write to the directory:
(though the folders are created, as can be seen in the explorer in the background)

@MarcoFalke That should fixed by #13426. You can merge these two PR and test locally.
555 | if (SUCCEEDED(hres))
556 | {
557 | // Get the current executable path
558 | - TCHAR pszExePath[MAX_PATH];
559 | - GetModuleFileName(nullptr, pszExePath, sizeof(pszExePath));
560 | + wchar_t pszExePath[MAX_PATH];
I think safer to use WCHAR here, as I'm seeing differing descriptions of its definition, e.g. unsigned wchar_t here: https://docs.microsoft.com/en-us/windows/desktop/intl/windows-data-types-for-strings
fixed
1117 | @@ -1118,9 +1118,9 @@ void AllocateFileRange(FILE *file, unsigned int offset, unsigned int length) { 1118 | #ifdef WIN32 1119 | fs::path GetSpecialFolderPath(int nFolder, bool fCreate) 1120 | { 1121 | - char pszPath[MAX_PATH] = ""; 1122 | + wchar_t pszPath[MAX_PATH] = L"";
Same, WCHAR seems preferable.
fixed
<!--e57a25ab6845829454e8d69fc972939a-->No more conflicts as of last run.
1117 | @@ -1118,9 +1118,9 @@ void AllocateFileRange(FILE *file, unsigned int offset, unsigned int length) { 1118 | #ifdef WIN32 1119 | fs::path GetSpecialFolderPath(int nFolder, bool fCreate) 1120 | { 1121 | - char pszPath[MAX_PATH] = ""; 1122 | + WCHAR pszPath[MAX_PATH] = L""; 1123 | 1124 | - if(SHGetSpecialFolderPathA(nullptr, pszPath, nFolder, fCreate)) 1125 | + if(SHGetSpecialFolderPathW(nullptr, pszPath, nFolder, fCreate))
nit: the failure message below references SHGetSpecialFolderPathA
fixed
utACK b446918
nice cleanup, too
utACK bb6ca65f9890e8280ace32de5a37774e14705859