The single buffer IncrementCounterByOne generated a Valgrind finding on ARM. This commit uses the same pattern for both overloads in case Valgrind wants to fire on the two-buffer version.
This was introduced earlier in the day when clearing a Valgrind finding. It tested good with the self tests. However, we double process byte[0] if there's a carry.
This was added to misc.h due to the noise created by NumericLimitsMin and NumericLimitsMax. It should make it easier to remove -Wno-unused-function from config.h.
Autotools sets up its config.h file with the '#define XXX 0' or '#define XXX 1' pattern. This check-in makes the sources Autotools aware. We need to verify CMake does the same
Commit afbd3e60f6 effectively treated a symptom and not the underlying problem. The problem was linkers on 32-bit systems ignore CRYPTOPP_ALIGN_DAT(16) passed down by the compiler and align to 8-bytes or less. We have to use Wei's original code in some places. It is not a bad thing, but the bit fiddling is something we would like to contain a little more by depending more on language or platform features.
This commit keeps the original changes which improve partial specializations; but fixes 32-bit linker behavior by effectively reverting afbd3e60f6 and e054d36dc8. We also add more comments so the next person has understands why things are done they way they are.
These fixes were interesting in a morbid sort of way. I thought the FixedSizeAllocatorWithCleanup specializations faithfully reproduced semantics but I was wrong on Win32 and Sparc. Also see Commit e054d36dc8.
It seems there was another requirement or dependency that we missed, but it was not readily apparent. If I am parsing results correctly (which I may not be), it appears the bit twiddling using 8 byte alignment had more influence on alignment than I originally thought based on use of CRYPTOPP_BOOL_ALIGN16 and T_Align16. Or maybe the alignment attributes specified by CRYPTOPP_ALIGN_DATA are not being honored like they should for stack allocations.
This check-in avoids some uses of x86 movdqa (aligned) in favor of movdqu (unaligned). The uses were concentrated on memory operands which were 8-byte aligned instead of 16-byte aligned. It is not clear to me how the specializations lost 8-bytes of alignment. The check-in also enlists CRYPTOPP_ASSERT to tell us when there's a problem so we don't need to go hunting for bugs.
It looks like GetAlignmentOf was returning the "UnsignedMin(4U, sizeof(T))" for SunCC. It was causing SIGBUSes on Sparc when T=word64. OpenCSW provided access to their build farm and we were able to test "__alignof__(T)" back to an early SunCC on Solaris 9.
Man, Sparc does not mess around with unaligned buffers. Without -xmemalign=4i the hardware wants 8-byte aligned word64's so it can use the high performance 64-bit move or add.
Since we do not use -xmemalign we get the default behavior of either -xmemalgin=8i or -xmemalgin=8s. It shoul dnot matter to us since we removed unaligned data access at GH #682.
We were able to gut CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS for everything except Rijndael. Rijndael uses unaligned accesses on x86 to harden against timing attacks.
There's a little more to CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS and Rijndael. If we remove unaligned access then AliasedWithTable hangs in an endless loop on non-AESNI machines. So care must be taken when trying to remove the vestige from Rijndael.
* remove superfluous semicolon
* Remove C-style casts from public headers
clang warns about them with -Wold-style-cast. It also warns about
implicitly casting away const with -Wcast-qual. Fix both by removing
unnecessary casts and converting the remaining ones to C++ casts.
The commit also adds an assert on memcpy_s pointers. GCC 8 claims the pointers are the same. We think it is a spurious finding. The assert never fired during test.
* Conditionally use a lambda rather than the older `bind2nd` style.
* Duplicate the if statements.
* Centralise the conditional compilation to an implementation of find_if_not.
* Refactoring of name and code placement after review.
* Use `FindIfNot` where appropriate.
* Remove whitespace.
The template functions take the rotate amount as a template parameter, which will allow the constexpr to propagate into the rotate expression. It should avoid some of the compile problems we were seeing under Clang and C++11
StringWiden converts a narrow C-style string to a wide string. It serves the opposite role of StringNarrow function. The function is useful on Windows platforms where the OS favors wide functions with the UTF-16 character set. For example, the Data Proction API (DPAPI) allows a description, but its a wide character C-string. There is no narrwo version of the API.
MOVBE is a modest gain over BSWAP. Though its guarded by CRYPTOPP_MOVBE_AVAILABLE, we cannot detect availability with a preprocessor macro. That is, GCC does not provide __MOVBE__ or similar. It has to be enabled manually
Benchmarking showed the use of the macros slowed things down. Profile guided bracnh reordering, committed at dc99266599a0e72d, provided a better benefit
ModPowerOf2 was changed to include a saturating subtract. Unintuitively, the code got faster rather than slower. The saturating operation appears to have helped the optimizer
This avoids a circular dependency between misc.h and trap.h. It also allows us to logically segregate and group code to replace C++ handlers, like set_terminate
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
__BIGGEST_ALIGNMENT__ is provided by some compilers, like GCC and ICC (but not Clang). It is usually 16 on 64-bit platforms; and it is usually 8 on 32-bit platforms
