commit | a943613e4060fd19258e4ae82491af8f98d5e2a1 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Sun Sep 23 18:36:01 2018 -0500 |
committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Mon Oct 01 22:57:00 2018 +0000 |
tree | bb09e41fa9a26650f636680cddb873534611a881 | |
parent | 7c3ce519e80122fa3ba326dc0aa5c8576ccd1250 [diff] |
Inline functions are apparently really complicated. C and C++ handle inline functions differently. In C++, an inline function is defined in just the header file, potentially emitted in multiple compilation units (in cases the compiler did not inline), but each copy must be identical to satsify ODR. In C, a non-static inline must be manually emitted in exactly one compilation unit with a separate extern inline declaration. In both languages, exported inline functions referencing file-local symbols are problematic. C forbids this altogether (though GCC and Clang seem not to enforce it). It works in C++, but ODR requires the definitions be identical, including all names in the definitions resolving to the "same entity". In practice, this is unlikely to be a problem, but an inline function that returns a pointer to a file-local symbol could compile oddly. Historically, we used static inline in headers. However, to satisfy ODR, use plain inline in C++, to allow inline consumer functions to call our header functions. Plain inline would also work better with C99 inline, but that is not used much in practice, extern inline is tedious, and there are conflicts with the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline For dual C/C++ code, use a macro to dispatch between these. For C++-only code, stop using static inline and just use plain inline. Update-Note: If you see weird C++ compile or link failures in header functions, this change is probably to blame. Though this change doesn't affect C and non-static inline is extremely common in C++, so I would expect this to be fine. Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82 Reviewed-on: https://boringssl-review.googlesource.com/32116 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: 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.
There are other files in this directory which might be helpful: