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
As reported in #520, C++Builder standard libraries don't have a `log()` function at global namespace. Change the invocations to unqualified name lookup, and apply a using-declaration to `std::log()` when compiling under C++Builder.
This may cause GH #300, "Clang 3.9 and missing member definitions for template classes" or GH #294, "Fix clang warnings about undefined variable templates in pkcspad.h" to resurface. Man I hope not...
This may cause GH #300, "Clang 3.9 and missing member definitions for template classes" or GH #294, "Fix clang warnings about undefined variable templates in pkcspad.h" to resurface. Man I hope not...
We were cating UBsan findings under Clang similar to "adv-simd.h:1138:26: runtime error: addition of unsigned offset to 0x000002d41410 overflowed to 0x000002d41400". The problem was CRYPTOPP_CONSTANT, which used an enum. The compiler is allowed to pick the underlying data type, and Clang was picking a signed type
* GNUmakefile-cross: Fix install target
The install target was not working: missing mkdir before copying files,
wrong dynamic library copied, missing ldconf.
The fix is mostly taken from the install target from GNUmakefile.
* Makefile: call 'ln -sf' instead of 'ln -sf -sf'
Power4 lacks 'vector long long'
Rename datatypes such as 'uint8x16_p8' to 'uint8x16_p'. Originally the p8 suffix indicated use with Power8 in-core crypto. We are now using Altivec/Power4 for general vector operations.
Power4 lacks 'vector long long'
Rename datatypes such as 'uint8x16_p8' to 'uint8x16_p'. Originally the p8 suffix indicated use with Power8 in-core crypto. We are now using Altivec/Power4 for general vector operations.
Power4 lacks 'vector long long'
Rename datatypes such as 'uint8x16_p8' to 'uint8x16_p'. Originally the p8 suffix indicated use with Power8 in-core crypto. We are now using Altivec/Power4 for general vector operations.
AES does not have a NEON implementation. However, because it includes "adv-simd.h", it needs the compiler options so NEON types are available. Otherwise the compile fails.
We can't guard "adv-simd.h" and NEON on just AES because Simon and Speck use the templates in their NEON implementations.
This also fixes the SPECK64 bug where CTR mode self tests fail. It was an odd failure because it only affected 64-bit SPECK. SIMON was fine and it used nearly the same code. We tracked it down through trial and error to the table based rotates.