| commit | 3251ca1f63ff8c9ea760c0046309e93596f6c12b | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu Jan 12 16:04:58 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Jan 13 21:16:11 2023 +0000 |
| tree | 1dd5ff862d5811e67c0decd3b5d1b0845157b57f | |
| parent | a230a8205e8f87893182a39756948526beb1d579 [diff] |
Simplify MSVC warning configuration We've been setting /Wall on MSVC for a while, but /Wall in MSVC is really "all". I.e., it's -Weverything in Clang and GCC, and includes many warnings that are simply diagnostics. MSVC's own headers do not promise to be clean under /Wall. Rather, the equivalent of Clang and GCC's -Wall is /W4, which MSVC does promise to pass. Under /Wall, every new MSVC release we've had to update an ever-growing list of warning exceptions, to disable the off-by-default warnings that were off for a reason. Switch to MSVC's recommendations and just enable /W4. From there, I've trimmed the exception list, now that we don't need to re-disable disabled warnings. A few non-disabled warnings also no longer need exceptions. This should fix the build with VS2022, which was failing due to C5264. C5264 flags a couple of instances in the library, but tons and tons in MSVC headers and googletest. (The instances in the library are a little goofy and reflect things that should have been 'inline constexpr', but we can't rely on C++17 yet. Though I may go add a compat macro for that.) Fixed: 552 Change-Id: I9031c0d5bd4c7a4df1dc3040b38af9cfbcffc06e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56045 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: