It is easier to defer to the runtime for aligned allocations. We found the preprocessor macros needed to identitify the availability. Also see https://forum.kde.org/viewtopic.php?p=66274
It is easier to defer to the runtime for aligned allocations. We found the preprocessor macros needed to identitify the availability. Also see https://forum.kde.org/viewtopic.php?p=66274
This commit does a few things. First, it uses the compiler's triplet and the build component to determine the machine we are targeting. Second, it adds an 'X' prefix so we don't collide with someone else's variables. Third it cleans up some of the recipes. Fourth, it removes X32 detection since the system differences are handled in config.h and the source files
Linuxbrew is a fork of Homebrew on Linux.
In which, the `gcc --version` will report "homebrew".
Therefore, the current code will incorrectly set OSXPORT_COMPILER
under such environment, which results to the following compiling errors:
gcm.cpp:823: Error: too many memory references for `add'
gcm.cpp:824: Error: too many memory references for `pxor'
gcm.cpp:825: Error: ambiguous operand size for `shr'
gcm.cpp:826: Error: too many memory references for `movzx'
gcm.cpp:827: Error: too many memory references for `add'
gcm.cpp:828: Error: too many memory references for `pxor'
gcm.cpp:829: Error: too many memory references for `movzx'
gcm.cpp:830: Error: too many memory references for `add'
gcm.cpp:831: Error: too many memory references for `pxor'
gcm.cpp:832: Error: ambiguous operand size for `add'
gcm.cpp:833: Error: ambiguous operand size for `sub'
gcm.cpp:835: Error: too many memory references for `movdqa'
g++-5 -DNDEBUG -g2 -O3 -fPIC -Wa,-q -DCRYPTOPP_CLANG_INTEGRATED_ASSEMBLER=1 -pthread -pipe -c md4.cpp
make: *** [GNUmakefile:1120: gcm.o] Error 1
make: *** Waiting for unfinished jobs....
Fix this problem by checking IS_DARWIN before setting OSXPORT_COMPILER.
Analysis tools are generating findings when the pointer xorBlocks is used as the flag. The other missing piece is, xorBlocks is never NULL when either BT_XorInput or BT_XorOuput. But we don't know how to train the analyzers with the information, so we make it explicit with the boolean flags xorInput and xorOutput.
Switching to the explicit flags costs us about 0.01 cpb on a modern Intel Core processor. In the typical case 0.01 is negligible.
vector_ptr was added at Crypto++ 5.6.5 to manage an array acquired with new[] in C++03. We can now use a combination of SecBlock and SetMark(0) to achieve the same effect.
Well, the IBM docs were not quite correct when they stated "The block is aligned so that it can be used for any type of data". The vector data types are pretty standard, even across different machines from diffent manufacturers
