Instead of building the test suites inherited from BoringSSL as
seperate executables, link them all together into one executable,
giving all their `main` functions unique names.
This allows all the tests to be run, even on platforms that don't have
traditional process spawning, and avoids the need to keep track of
directory names even on platforms that do support process spawning.
This also makes it easier to integrate new BoringSSL test suites on
Windows, because we don't need to create a new `vcxproj` file for each
one.
Having one test executable may also make code coverage easier.
All the test cases in gcm_test (except the AES-192 test vectors we
don't care about) are already tested in the AEAD tests; i.e.
aes_128_gcm_tests.txt and aes_256_gcm_tests.txt already contain all
the test vectors in gcm_test.c.
This code seems to test weird things that I don't understand. I think
it might be some very important regression test for some very important
bug that was fixed, or maybe it is a special test for p256-64.c or
something. Regardless, it was in the way removing it gets it out of the
way. This may not be the best course of action; if not, then it would
be great to learn what this is for.
Maintaining the error state is shockingly complicated and error-prone.
Since all the readers of the error state have been removed, we can
avoid maintaing it at all, avoiding all that complexity.
There are about 500 calls to |OPENSSL_PUT_ERROR| in the code. This
change makes them all a no-op. This will reduce code size. The calls to
|OPENSSL_PUT_ERROR| were left in the code to keep syncing with
upstreams easy.
fix error removal.
* Fix typo in a comment in mk/top_of_makefile.mk.
* Update ring.sln to mention VS 2015 RTM version.
* Suppress variable shadowing warning on Windows in mk/Common.props.
* Silence some warnings about things that MSVC 2015 warns about that
MSVC 2013 didn't.
* Change the solution so that it opens in Visual Studio 2015 if Visual
Studio 2015 is installed.
* Change ToolsVersion to 14.0 in the project files so that Visual
Studio 2015 does not put a warning in the build log about the version
being 12.0. This means that Visual Studio 2013 will have a warning,
but the warning is harmless, and if we have to choose, it's better
for VS 2013 to warn than VS 2015 to warn, in the long term. See
https://github.com/Microsoft/msbuild/issues/52#issuecomment-88674094.
* Build with the VS 2013 XP-compatible toolchain if using Visual Studio
2013 (including its msbuild); Otherwise build with the Visual Studio
2015 XP-compatible toolchain. See
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ \
d06c3741-c637-4627-9b1a-1e068803a067/ \
setting-platformtoolset-value-based-on-vs-version.
Much of the repetitive logic was put into mk/Common.props,
mk/Windows.props, and mk/WindowsTest.props. There is still a lot of
repetitive logic in the test project files that should be moved to
WindowsTest.props in the future. (In fact, it would be better if the
build system were modified in the future to work like CMake does,
(re-)generating the necessary project files during the build.)
Regular (OPENSSL_NO_ASM) mode will come in a later commit.
I've marked the Visual Studio files as eol=crlf in .gitattributes for
now. This should be the least painful option, since it any CRLF
conversion would create problems for for people sharing a source tree
across platforms (e.g. a shared folder in a VM), and because Visual
Studio IDE resets the files back to CR/LF line endings whenever a
change to project or solution settings is made using its GUI. There is
no license comment in these files because Visual Studio strips comments
when changes are made using the GUI.
