* Set default target Windows version for MinGW to XP
The original MinGW from mingw.org targets Windows 2000 by default, but lacks
the <wspiapi.h> include needed for Windows 2000 support.
* Disable CRYPTOPP_CXX11_SYNCHRONIZATION for original MinGW
std::mutex is only available in libstdc++ if _GLIBCXX_HAS_GTHREADS is defined,
which is not the case for original MinGW. Make the existing fix for AIX more
general to fix this. Unfortunately, any C++ header has to be included to
detect the standard library and the otherwise empty <ciso646> is going to be
removed from C++20, so use <cstddef> instead.
Add tests for Support for Control-flow Enforcement Technology (CET). This is an upcoming processor feature. We want to be out in front of breaks to our inline assembly
This cleans up the compile on old PwerMac G5's. Our Altivec and Crypto code relies on Power7 and Power8 extensions. There's no need to shoehorn Altivec and Power4 into old platforms, so we disable Altivec and Crypto unless Power7 is available. The GNUmakefile sets CRYPTOPP_DISABLE_ALTIVEC if Power7 is not available.
Enable aligned allocations under IBM XL C/C++. Based on the AIX malloc man pages, "... the block is aligned so that it can be used for any type of data". Previously CRYPTOPP_NO_ALIGNED_ALLOC was in effect.
Use malloc instead of calloc on OS X. Based on the OS X malloc man pages, "... the allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types". Additionally, calloc zero'd the memory it allocated which slowed things down on Apple systems.
This is the first of possibly two or three for Borland compilers. We have to be careful because its very easy to break something due to math overloads with other compilers like SunCC or XL/C
This avoids the probe for SSE2 in most circumstances. The SSE2 test is mostly benign nowadays since SSE2 and OS support is nearly ubiquitous. But the define CRYPTOPP_NO_CPU_FEATURE_PROBES added for Apple OSes was interacting badly on x86 machines. Also see GH #511.
UncheckedSetKey has traditionally been a protected member function. The public API traditionally uses SetKey (and friends) to set the key. Internally, SetKey may call UncheckedSetKey. It looks like UncheckedSetKey was made public when authenticated encryption support was added.
Its probably not a good idea to have users calling UncheckedSetKey. Most (all?) of the time it does nothing for authenc modes. The other remaining cases it may not work as expected.
Move m_aliasBlock into Rijndael::Base. m_aliasBlock is now an extra data member for Dec because the aliased table is only used for Enc when unaligned data access is in effect. However, the SecBlock is not allocated in the Dec class so there is no runtime penalty.
Moving m_aliasBlock into Base also allowed us to remove the Enc::Enc() constructor, which always appeared as a wart in my eyes. Now m_aliasBlock is sized in UncheckedSetKey, so there's no need for the ctor initialization.
Also see https://stackoverflow.com/q/46561818/608639 on Stack Overflow. The SO question had an unusual/unexpected interaction with CMake, so the removal of the Enc::Enc() ctor should help the problem.
Add m_isSpecial, m_mandatoryBlockSize and m_optimalBufferSize members. The additional members stabilize running times and avoid some unnecessary calculations. Previously we were calculating some values in each call to Put and LastPut.
CC optimizes things best when isSpecial uses the two predicates. If the 'm_cipher.MandatoryBlockSize() > 0' is removed, then some block ciphers and modes lose up to 0.2 cpb. Apparently GCC can optimize away the second predicate easier than the first predicate.
Jeffrey Walton
Marcel Raad