refactor: Change occurences of c_str() used with size() to data() #17280

Using data() better communicates the intent here.

Also, depending on how c_str() is implemented, this fixes undefined behavior: The part of the string after the first NULL character might have undefined contents (or even be inaccessible, worst case). Apparently this is no longer an issue with C++11.

Code review ACK f3b51eb

Concept ACK

What about linting this to make sure this is a one-time fix-up?

Suggested lint command:

$ git grep -E '([a-zA-Z0-9_]+).c_str\(\)+[^a-zA-Z0-9_]+\1\.size\(\)' -- "*.cpp" "*.h"
src/bitcoin-cli.cpp:        char *encodedURI = evhttp_uriencode(walletName.c_str(), walletName.size(), false);
src/crypto/hkdf_sha256_32.cpp:    CHMAC_SHA256((const unsigned char*)salt.c_str(), salt.size()).Write(ikm, ikmlen).Finalize(m_prk);
src/fs.cpp:    int size = MultiByteToWideChar(CP_ACP, 0, mb_string.c_str(), mb_string.size(), nullptr, 0);
src/fs.cpp:    MultiByteToWideChar(CP_ACP, 0, mb_string.c_str(), mb_string.size(), &*utf16_string.begin(), size);
src/httprpc.cpp:        CHMAC_SHA256(reinterpret_cast<const unsigned char*>(strSalt.c_str()), strSalt.size()).Write(reinterpret_cast<const unsigned char*>(strPass.c_str()), strPass.size()).Finalize(out);
src/util/strencodings.cpp:    return EncodeBase64((const unsigned char*)str.c_str(), str.size());
src/util/strencodings.cpp:    return EncodeBase32((const unsigned char*)str.c_str(), str.size());
src/wallet/crypter.cpp:    di.Write((const unsigned char*)strKeyData.c_str(), strKeyData.size());

What about linting this to make sure this is a one-time fix-up?

Maybe—It could catch some of them, I guess. But only if they're on the same line? (which is the case for all of these, admittedly)

@laanwj Correct, multi-line search with git grep is not possible AFAIK, so there could be false negatives.

Code review ACK f3b51eb9352d7a7c5dfa15615efc8bc0a52ffecf. Most of these calls (including one in crypter.cpp) are passing text strings, not binary strings likely to contain \0 and were probably safe before, but much better to avoid the possibility of bugs like this.

We are using C++11 and according to https://en.cppreference.com/w/cpp/string/basic_string/c_str this is safe.

c_str() and data() perform the same function. | (since C++11)

I have removed the "bug" label and added the "Refactoring" label.

Concept ACK, though.

ACK f3b51eb9352d7a7c5dfa15615efc8bc0a52ffecf -- diff looks correct, data() more idiomatic