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
Jeffrey Walton
Marcel Raad
Ilja
Kirit Sælensminde
klemens