cryptest.sh revealed a corner case still producing an incorrect result. We need to check for '*this > m', not '*this > 2m-1'.
The corner case looks obscure. The failure surfaced as 1 failed self test for about every 2048 tests. It was also in a code path where 'a' was explicitly set to '2m-1', with 'm' random.
The test result can be duplicated with 'cryptest.exe v 9996 1521969687'. The value '1521969687' is a seed for the random number generator to reproduce.
This commit also tweaks the way Integer parses byte arrays. The modified routines are slightly faster. On a Core-i5 6400 the self tests are 0.1 to 0.2 seconds faster
Currently the CRYPTOPP_BOOL_XXX macros set the macro value to 0 or 1. If we remove setting the 0 value (the #else part of the expression), then the self tests speed up by about 0.3 seconds. I can't explain it, but I have observed it repeatedly.
This check-in prepares for the removal in Upstream master
* Fix compilation on Windows with /DUNICODE
* Fix linking of fipstest for MSVC targeting ARM (__crt_debugger_hook is not available).
* Fix build for Clang on Windows with optimizations on.
* Fix a warning about a non-existant warning under Clang.
* Fix compilation under Intel C++ 18.0 on Windows
Couple use of initialization priorities to no NO_OS_DEPENDENCE
Add comments explaining what integer does, how it does it, and why we want to inprove on the Singleton pattern as a resource manager.
Update documentation.
This effectively decouples Integer and Public Key from the rest of the library. The change means a compile time define is used rather than a runtime pointer. It avoids the race with Issue 389.
The Public Key algorithms will fail if you use them. For example, running the self tests with CRYPTOPP_NO_ASSIGN_TO_INTEGER in effect results in "CryptoPP::Exception caught: NameValuePairs: type mismatch for 'EquivalentTo', stored 'i', trying to retrieve 'N8CryptoPP7IntegerE'". The exception is expected, and the same happend when g_pAssignIntToInteger was present.
Wrap DetectArmFeatures and DetectX86Features in InitializeCpu class
Use init_priority for InitializeCpu
Remove HAVE_GCC_CONSTRUCTOR1 and HAVE_GCC_CONSTRUCTOR0
Use init_seg(<name>) on Windows and explicitly insert at XCU segment
Simplify logic for HAVE_GAS
Remove special recipies for MACPORTS_GCC_COMPILER
Move C++ static initializers into anonymous namespace when possible
Add default NullNameValuePairs ctor for Clang
When MSVC init_seg or GCC init_priority is available, we don't need to use the Singleton. We only need to create a file scope class variable and place it in the segment for MSVC or provide the attribute for GCC.
An additional upside is we cleared all the memory leaks that used to be reported by MSVC for debug builds.
This avoids a potential problem when OR'ing with 0 that results in a WordCount() of 1. Integer's minimum reg[] size is 2 due to RoundupSize(), and there could be implicit assumptions for the minimum that did not surface under testing
This avoids a potential problem when OR'ing with 0 that results in a WordCount() of 1. Integer's minimum reg[] size is 2 due to RoundupSize(), and there could be implicit assumptions for the minimum that did not surface under testing
This may not fix the issue. Drilling into the issue from the web-based dashboard, Coverity is targeting:
1. noescape: CryptoPP::Integer::operator =(CryptoPP::Integer const &) does not free or save its parameter t.
3049 Integer& Integer::operator=(const Integer& t)
3050 {
3051 if (this != &t)
3052 {
3053 if (reg.size() != t.reg.size() || t.reg[t.reg.size()/2] == 0)
3054 reg.New(RoundupSize(t.WordCount()));
3055 CopyWords(reg, t.reg, reg.size());
3056 sign = t.sign;
3057 }
3058 return *this;
3059 }
trap.h and CRYPTOPP_ASSERT has existed for over a year in Master. We deferred on the cut-over waiting for a minor version bump (5.7). We have to use it now due to CVE-2016-7420
