Hey everyone, I've ran the build of our current GitHub hosted sources on my VS 2015 installation and found the following warnings (build related, migration's a different story)
The following warnings appear in Debug and Release 32-bit and 64-bit builds: We're getting a C4297 <https://msdn.microsoft.com/en-us/library/84e2zwhh.aspx> on the destructor of AlgorithmParameterBase (line 271 in algparam.h). The fix would be to remove this line. The problem I see here: Why do we even have a conditional throw in a *destructor*? Is there any /really/ good rationale there? Is there any way to do whatever the throw should do without throwing? We're getting another C4297 in the ThreadLocalStorage destructor (line 38 in trdlocal.cpp) which throws on free-error. I'm not sure how to mitigate this one. We're getting a few C4996 <https://msdn.microsoft.com/en-us/library/ttcz0bys.aspx> warnings in sockeft.cpp (lines 102, 136, 140) because we're using a deprecated API there. The called functions were considered standard some years ago, but will be replaced in the future. The compiler proposes replacing "inet_addr" by "inet_pton() or InetPton()" and replacing "gethostbyname" by "getaddrinfo() or GetAddrInfoW()". I think we need to check availability of these instructions on VS 2005 before actually doing this. Next is a standard C4242 <https://msdn.microsoft.com/en-us/library/3hca13eh.aspx> in zdeflate.cpp (line 642), we're converting an unsigned integer (32-bit) into a word16. I think we can safely change the type of the m_blockLength from "unsigned int" to "word16" as the assert already implies the range beyond 16 bit was never intended. Now comes another C4242 <https://msdn.microsoft.com/en-us/library/3hca13eh.aspx> in nbtheory.cpp (line 48), we're converting an unsigned integer (32-bit) into a word16. I think we can safely change the type of the p from "unsigned int" to "word16" as the vector where it's being pushed into already uses word16s. Finally we're getting a bunch of LNK4221 <https://msdn.microsoft.com/en-us/library/604bzebd.aspx> warnings for strciphr.obj (= compiled version of strciphr.cpp), simple.obj, polynomi.obj and algebra.obj. I just checked and simple.cpp actually does /nothing/, algebra.cpp is sometimes included in algebra.h to provide manual instantiations of templates, strciphr.cpp does the same as algebra.cpp for strciphr.h, polynomi.cpp is the same case as algebra. This error happened on static library build and we could fix it by manually excluding those source files from the build, the #define-constant necessary for inclusion is only defined in a dll build apparently. (This one seems to be debug-exclusive) The last one on the list is a C4191 <https://msdn.microsoft.com/en-us/library/w0eaaaf7%28v=vs.100%29.aspx> in dll.cpp (line 85), we're doing an unsafe (function?) pointer conversion there. It looks like we have to do pointer conversion there so may can fix this by using static_cast<>() instead of the C-style conversion. But I'm not sure about this one. What I'll tackle tomorrow: Try to apply the proposed fixes above, create up to 7 PRs for GitHub (up to one for each change) and see what happens in the crazy DLL-Import builds then. BR JPM -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
