* Put AES ctx on the heap
This forces people to use the ``ctx_release`` functions, because otherwise there will be leaks
* Put fips202 on the heap
* Add much more docs for fips202.h
* fixup! Put fips202 on the heap
* Put SHA2 on the heap-supporting API
* Fix clang-tidy warnings
* Fix unreachable free() in falcon
* Fix McEliece8192128f-sse GNU Makefile
* Fix alignment problems with vectors
* Fix required CPU flags for McEliece
* Fix McElice8192128f that was missed in #259
* fixup! Fix McElice8192128f that was missed in #259
* Fix initialization
* Add McEliece reference implementations
* Add Vec implementations of McEliece
* Add sse implementations
* Add AVX2 implementations
* Get rid of stuff not supported by Mac ABI
* restrict to two cores
* Ditch .data files
* Remove .hidden from all .S files
* speed up duplicate consistency tests by batching
* make cpuinfo more robust
* Hope to stabilize macos cpuinfo without ccache
* Revert "Hope to stabilize macos cpuinfo without ccache"
This reverts commit 6129c3cabe1abbc8b956bc87e902a698e32bf322.
* Just hardcode what's available at travis
* Fixed-size types in api.h
* namespace all header files in mceliece
* Ditch operations.h
* Get rid of static inline functions
* fixup! Ditch operations.h
* Add state destroy to SHA2 API
* Include optimized SPHINCS+ implementations
I've generated new implementations from the sphincsplus repository.
* Don't destroy sha256ctx after finalize
* Attempt to shut up MSVC
* Make sure to drop errors in rmtree
clang-tidy9.0.0 added a new check: bugprone-branch-clone
(https://releases.llvm.org/9.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html)
This doesn't like both branches of an if are the same.
This lead to a warning in rainbow, as where the maximum of two values (which
are always the same) is computed in a macro.
I don't always agree with this warning, but here I think it's worth to
remove the macro.
clang9.0.0 (https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html)
adds a new satic analyzer: security.insecureAPI.DeprecatedOrUnsafeBufferHandling
which throws warnings if you use "unsafe" buffer handling functions which
includes memset and memcpy.
We have memset and mempy all over the place, so I think it's best to ignore this warning.
All the occurences that I looked at seemed perfectly "safe" to me.
