Unfortunately, it's not enough to be able to turn it on thanks to the
PURE_VIRTUAL macro. But it gets us most of the way there.
Change-Id: Ie6ad5119fcfd420115fa49d7312f3586890244f4
Reviewed-on: https://boringssl-review.googlesource.com/c/34949
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The change seems to have stuck, so bring us closer to C/++11 static asserts.
(If we later find we need to support worse toolchains, we can always use
__LINE__ or __COUNTER__ to avoid duplicate typedef names and just punt on
embedding the message into the type name.)
Change-Id: I0e5bb1106405066f07740728e19ebe13cae3e0ee
Reviewed-on: https://boringssl-review.googlesource.com/c/33145
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I4ec8a21264c2c73ebf8ca6a93b96eba29bd2d29e
Reviewed-on: https://boringssl-review.googlesource.com/c/32345
Reviewed-by: Robert Sloan <varomodt@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
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>
The calls to qsort and bsearch are still invalid, but not avoidable
without reimplementing them. Fortunately, they cross libraries, so CFI
does not object.
With that, all that's left is LHASH!
Bug: chromium:785442
Change-Id: I6d29f60fac5cde1f7870d7cc515346e55b98315b
Reviewed-on: https://boringssl-review.googlesource.com/32114
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>
Unfortunately, some projects are calling into sk_pop_free directly, so
we must leave a compatibility version around for now.
Bug: chromium:785442
Change-Id: I1577fce6f23af02114f7e9f7bf2b14e9d22fa9ae
Reviewed-on: https://boringssl-review.googlesource.com/32113
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>
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Updating clang seems to have upset the clang-cl build. I think because
they decided -Wall now matches MSVC's semantics, which is a little nuts.
Two of the warnings, however, weren't wrong, so fix those.
http://llvm.org/viewvc/llvm-project?view=revision&revision=319116
Change-Id: I168e52e4e70ca7b1069e0b0db241fb5305c12b1e
Reviewed-on: https://boringssl-review.googlesource.com/24684
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
DECLARE_STACK_OF adds a trailing ; so we don't need a second one added
here.
Compiling a project using boringssl which uses -Werror,-Wextra-semi I
get errors:
```
third_party/boringssl/include/openssl/stack.h:374:1: error: extra ';' outside of a function [-Werror,-Wextra-semi]
DEFINE_STACK_OF(void)
^
third_party/boringssl/include/openssl/stack.h:355:3: note: expanded from macro 'DEFINE_STACK_OF'
BORINGSSL_DEFINE_STACK_OF_IMPL(type, type *, const type *) \
^
third_party/boringssl/include/openssl/stack.h:248:25: note: expanded from macro 'BORINGSSL_DEFINE_STACK_OF_IMPL'
DECLARE_STACK_OF(name); \
^
third_party/boringssl/include/openssl/stack.h:375:1: error: extra ';' outside of a function [-Werror,-Wextra-semi]
DEFINE_SPECIAL_STACK_OF(OPENSSL_STRING)
^
third_party/boringssl/include/openssl/stack.h:369:3: note: expanded from macro 'DEFINE_SPECIAL_STACK_OF'
BORINGSSL_DEFINE_STACK_OF_IMPL(type, type, const type)
^
third_party/boringssl/include/openssl/stack.h:248:25: note: expanded from macro 'BORINGSSL_DEFINE_STACK_OF_IMPL'
DECLARE_STACK_OF(name); \
^
2 errors generated.
```
Change-Id: Icc39e2341eb76544be72d2d7d0bd29e2f1ed0bf9
Reviewed-on: https://boringssl-review.googlesource.com/23404
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
ssl is all that's left. Will do that once that's at a quiet point.
Change-Id: Ia183aed5671e3b2de333def138d7f2c9296fb517
Reviewed-on: https://boringssl-review.googlesource.com/19564
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Pushing entries onto a stack when handling malloc failures is a
nuisance. sk_push only takes ownership on success. PushToStack smooths
that over with a UniquePtr.
Bug: 132
Change-Id: I4f0a9eee86dda7453f128c33d3a71b550beb25e9
Reviewed-on: https://boringssl-review.googlesource.com/18468
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
My original plan here was to make STACK_OF(T) expand to a template so
the inner type were extractable. Unfortunately, we cannot sanely make
STACK_OF(T) expand to a different type in C and C++ even across
compilation units because UBSan sometimes explodes. This is nuts, but so
it goes.
Instead, use StackTraits to extract the STACK_OF(T) parameters and
define an iterator type.
Bug: 189
Change-Id: I64f5173b34b723ec471f7a355ff46b04f161386a
Reviewed-on: https://boringssl-review.googlesource.com/18467
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Rather than manually register the stack deleters separately, instantiate
them automatically from DEFINE_STACK_OF and BORINGSSL_MAKE_DELETER. The
StackTraits bridge in DEFINE_STACK_OF will additionally be used for
other C++ STACK_OF conveniences.
Bug: 132
Change-Id: I95d6c15b2219b34c7a8ce06dd8012d073dc19c27
Reviewed-on: https://boringssl-review.googlesource.com/18465
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Instead of a script which generates macros, emit static inlines in
individual header (or C files). This solves a few issues with the
original setup:
- The documentation was off. We match the documentation now.
- The stack macros did not check constness; see some of the fixes in
crypto/x509.
- Type errors did not look like usual type errors.
- Any type which participated in STACK_OF had to be made partially
public. This allows stack types to be defined an internal header or
even an individual file.
- One could not pass sk_FOO_free into something which expects a function
pointer.
Thanks to upstream's 411abf2dd37974a5baa54859c1abcd287b3c1181 for the
idea.
Change-Id: Ie5431390ccad761c17596b0e93941b0d7a68f904
Reviewed-on: https://boringssl-review.googlesource.com/16087
Reviewed-by: Adam Langley <agl@google.com>
FIPS is not compatible with multiprime RSA. Any multiprime RSA private
keys will fail to parse after this change.
Change-Id: I8d969d668bf0be4f66c66a30e56f0e7f6795f3e9
Reviewed-on: https://boringssl-review.googlesource.com/14984
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I33a9cb2cc13f2ed64a6bf2728cd3fcc980e1408f
Reviewed-on: https://boringssl-review.googlesource.com/12161
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is unused.
Change-Id: I31bbfb88aa9b718083ecce6d1a834f27683cf002
Reviewed-on: https://boringssl-review.googlesource.com/10363
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is very far from all of it, but I did some easy ones before I got
bored. Snapshot the progress until someone else wants to continue this.
BUG=22
Change-Id: I2609e9766d883a273e53e01a75a4b1d4700e2436
Reviewed-on: https://boringssl-review.googlesource.com/9132
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts commits:
8d79ed674019fdcb52348d79ed6740
Because WebRTC (at least) includes our headers in an extern "C" block,
which precludes having any C++ in them.
Change-Id: Ia849f43795a40034cbd45b22ea680b51aab28b2d
MSVC doesn't define __cplusplus as 201103 to indicate C++11 support, so
just assume that the compiler supports C++11 if _MSC_VER is defined.
Change-Id: I27f6eeefe6e8dc522470f36fab76ab36d85eebac
Reviewed-on: https://boringssl-review.googlesource.com/8734
Reviewed-by: David Benjamin <davidben@google.com>
This change scatters the contents of the two scoped_types.h files into
the headers for each of the areas of the code. The types are now in the
|bssl| namespace.
Change-Id: I802b8de68fba4786b6a0ac1bacd11d81d5842423
Reviewed-on: https://boringssl-review.googlesource.com/8731
Reviewed-by: Adam Langley <agl@google.com>
We currently have the situation where the |tool| and |bssl_shim| code
includes scoped_types.h from crypto/test and ssl/test. That's weird and
shouldn't happen. Also, our C++ consumers might quite like to have
access to the scoped types.
Thus this change moves some of the template code to base.h and puts it
all in a |bssl| namespace to prepare for scattering these types into
their respective headers. In order that all the existing test code be
able to access these types, it's all moved into the same namespace.
Change-Id: I3207e29474dc5fcc344ace43119df26dae04eabb
Reviewed-on: https://boringssl-review.googlesource.com/8730
Reviewed-by: David Benjamin <davidben@google.com>
There's a few that can't work since the types don't even exist.
Change-Id: Idf860b146439c95d33814d25bbc9b8f61774b569
Reviewed-on: https://boringssl-review.googlesource.com/6762
Reviewed-by: Adam Langley <agl@google.com>
We never need to define the actual structs because we always cast them
before use. The types only exist to be distinct, and they can do that
without a definition.
Change-Id: I1e1ca0833b383f3be422675cb7b90dacbaf82acf
Reviewed-on: https://boringssl-review.googlesource.com/5593
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This change mirrors upstream's custom extension API because we have some
internal users that depend on it.
Change-Id: I408e442de0a55df7b05c872c953ff048cd406513
Reviewed-on: https://boringssl-review.googlesource.com/5471
Reviewed-by: Adam Langley <agl@google.com>
C99 doesn't, technically, allow empty statements. Thus if a #define'ed
function ends in a semicolon, and the use of it also ends in a
semicolon, then the compiler sees “;;” at the end.
Since a choice has to be made, I prefer that the semicolon exist at the
“callsite” of a #define'ed fuction. But I haven't gone and changed
everything to follow that in this patch.
Change-Id: I1343e52a5ac6255db49aa053048d0df3225bcf43
Reviewed-on: https://boringssl-review.googlesource.com/3890
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
I typoed this word and then auto-complete duplicated it all over the
place. This change fixes all the comments.
This change has no semantic effect (comment only).
Change-Id: I8952e9e71302043574757cd74a05e66500008432
This lets us put the SSL_CIPHER table in the data section. For type-checking,
make STACK_OF(SSL_CIPHER) cast everything to const SSL_CIPHER*.
Note that this will require some changes in consumers which weren't using a
const SSL_CIPHER *.
Change-Id: Iff734ac0e36f9e5c4a0f3c8411c7f727b820469c
Reviewed-on: https://boringssl-review.googlesource.com/1541
Reviewed-by: Adam Langley <agl@google.com>
This change marks public symbols as dynamically exported. This means
that it becomes viable to build a shared library of libcrypto and libssl
with -fvisibility=hidden.
On Windows, one not only needs to mark functions for export in a
component, but also for import when using them from a different
component. Because of this we have to build with
|BORINGSSL_IMPLEMENTATION| defined when building the code. Other
components, when including our headers, won't have that defined and then
the |OPENSSL_EXPORT| tag becomes an import tag instead. See the #defines
in base.h
In the asm code, symbols are now hidden by default and those that need
to be exported are wrapped by a C function.
In order to support Chromium, a couple of libssl functions were moved to
ssl.h from ssl_locl.h: ssl_get_new_session and ssl_update_cache.
Change-Id: Ib4b76e2f1983ee066e7806c24721e8626d08a261
Reviewed-on: https://boringssl-review.googlesource.com/1350
Reviewed-by: Adam Langley <agl@google.com>
Previously, public headers lived next to the respective code and there
were symlinks from include/openssl to them.
This doesn't work on Windows.
This change moves the headers to live in include/openssl. In cases where
some symlinks pointed to the same header, I've added a file that just
includes the intended target. These cases are all for backwards-compat.
Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92
Reviewed-on: https://boringssl-review.googlesource.com/1180
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).
(This change contains substantial changes from the original and
effectively starts a new history.)
