Need a potential changes tested on MinGW-64

[Jeffrey Walton]

Hi Everyone,

I need two potential changes tested for MinGW-64. Would someone please checkout the latest from master and perform the following two tests to see if they affect compile.

Clone the repo:

    git clone https://github.com/weidai11/cryptopp
    cd cryptopp

First test. Open validat1.cpp and completely comment out the following around line 175:

    #if defined(__MINGW32__)
      using CryptoPP::memcpy_s;
    #endif

Second test. Open validat1.cpp and limit the change to MinGW-64 around line 175:

    #if defined(__MINGW64__)
      using CryptoPP::memcpy_s;
    #endif

Please be sure to use the latest sources, and then report back with results. Thanks in advance.

[trungantran]

The first will break compilation if someone uses MinGW-w64 CRT with secure APIs support.
This is because we have two declaration of memcpy_s imported in global namespace (line 66):
USING_NAMESPACE(CryptoPP)

The second also break compilation if someone uses MinGW-w64 CRT v 3.x with secure APIs support.
This is because _MEMORY_S_DEFINED macro is defined in sec_api/memory_s.h, resulting in CryptoPP::memcpy_s not declared.

Note:
- v 4.x and later move memcpy_s to string.h and do not define _MEMORY_S_DEFINED anymore.
- v 3.x, 4.x, 5.x are used with GCC 4.x, 5.x, 6.x respectively.
- MINGW_HAS_SECURE_API is defined if CRT has support for secure APIs.
- __MINGW32__ is defined in both cases (32bit vs 64bit).

So I suggest a change as follow:
#if defined(__MINGW32__)
// avoid ambiguity if we have two versions of memcpy_s
#if !defined(MINGW_HAS_SECURE_API) || (MINGW_HAS_SECURE_API + 0 == 0) || defined(CRYPTOPP_WANT_SECURE_LIB)
using CryptoPP::memcpy_s;
#else
using ::memcpy_s;
#endif
#endif

[Jeffrey Walton]

So I suggest a change as follow:
#if defined(__MINGW32__)
// avoid ambiguity if we have two versions of memcpy_s
#if !defined(MINGW_HAS_SECURE_API) || (MINGW_HAS_SECURE_API + 0 == 0) || defined(CRYPTOPP_WANT_SECURE_LIB)
        using CryptoPP::memcpy_s;
#else
        using ::memcpy_s;
#endif
#endif

Oh, that's uglier than normal.

Are there any objections to the change outlined by trungantran?

trungantran, do you feel like making a pull request?

Jeff

[Jeffrey Walton]

On Sunday, October 16, 2016 at 3:48:34 AM UTC-4, trungantran wrote:

The first will break compilation if someone uses MinGW-w64 CRT with secure APIs support.
This is because we have two declaration of memcpy_s imported in global namespace (line 66):
USING_NAMESPACE(CryptoPP)

The second also break compilation if someone uses MinGW-w64 CRT v 3.x with secure APIs support.
This is because _MEMORY_S_DEFINED macro is defined in sec_api/memory_s.h, resulting in CryptoPP::memcpy_s not declared.

Note:
- v 4.x and later move memcpy_s to string.h and do not define _MEMORY_S_DEFINED anymore.
- v 3.x, 4.x, 5.x are used with GCC 4.x, 5.x, 6.x respectively.
- MINGW_HAS_SECURE_API is defined if CRT has support for secure APIs.
- __MINGW32__ is defined in both cases (32bit vs 64bit).

We cleared this using std::copy on Unix & Linux; and std::copy with a checked iterator on Microsoft platforms that support them.

  * http://github.com/weidai11/cryptopp/commit/51d3cc945fe388c776a1a20683ba8ff1c2f191e2

Jeff