Cryptopp: Don't use WSAStringToAddress, use WSAStringToAddressA instead

[asbai]

Otherwise it can't compiled under UNICODE mode. Because the code always use an ANSI char to receive the result:

    char temp[MAX_ADDRSTRLEN]; // ANSI char
    // ...
    if (WSAStringToAddress(temp, af, NULL, (struct sockaddr *)&ss, &size) == 0) { // ...

WSAStringToAddress is mapping to WSAStringToAddressW under UNICODE version, and WSAStringToAddressA under the ANSI version. Explicitly using WSAStringToAddressA if you always want to use the ANSI one.

[noloader]

Thanks @asbai.

It sounds like the build system is not quite correct. Can you verify CharacterSet is set to MultiByte in cryptlib.vcxproj:

  <!-- All Configurations -->
  <PropertyGroup Label="All Configurations">
    <ConfigurationType>StaticLibrary</ConfigurationType>
    <TargetName>cryptlib</TargetName>
    <TargetExt>.lib</TargetExt>
    <UseOfMfc>false</UseOfMfc>
    <CharacterSet>MultiByte</CharacterSet>
    <WholeProgramOptimization>true</WholeProgramOptimization>
  </PropertyGroup>

[asbai]

Ha, I'm not using the default vcproj and solution file belong with the source package. Actually, I'm build crypto++ by my own vc project files before many years ago. There is many reason to do that, for example: I need many components from different libraries can interactive with each others smoothly.

But I think it is not a "configuration problem", it is a code problem. Because we are using the MSBC (ANSI) char with a "TCHAR" API (WSAStringToAddress talk TCHAR). If we really want to talking with char, we should use the ANSI version (WSAStringToAddressA) to ensure it. So we can talk with MBCS charset no matter what configuration are using.

[denisbider]

@asbai is right that it is generally a good idea to identify the Windows function version (ANSI/Unicode) that the library wants to call explicitly, instead of relying on the macro. The only reason one would not identify the function version (A or W) is if you're writing code that uses TCHAR and is meant to be compiled as either ANSI or Unicode. However, this code clearly needs the A version of the function, so it's a good idea to specify the A version instead of using the A/W macro.

[noloader]

@asbai, @denisbider,

Thanks Denis. Does anyone feel like a pull request. Or can DB handle the check-in?

[denisbider]

Added "A" to this function's use in socketft.cpp. Done directly through GitHub interface. No testing performed. Have not searched for occurrences of this name elsewhere.

[noloader]

@denisbider, @asbai,

Thanks Denis. Should we open a ticket for "... identify the Windows function version (ANSI/Unicode) that the library wants to call explicitly, instead of relying on the macro"? Do we want to implement the policy library wide?

[asbai]

Except exactly this single one case, I can build and use the ANSI / Unicode version with no error.

[noloader]

@asbai,

I'm going to close this out now. I believe Denis cleared the WSAStringToAddress issue; and there does not appear to be interest in converting the remainder of the unspecified functions to ANSI/narrow functions.