| commit | 15ba28f839c828ced30178a86a9c56b104d3b5d7 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Jun 24 16:51:13 2022 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Oct 11 18:44:26 2022 +0000 |
| tree | 1a8540be1b1e328092162a83b0eb354f1db1ed64 | |
| parent | 19d6ec9c439323c869e28f4e496329e55179f1ee [diff] |
Make CBB_init_fixed infallible and allocationless. Today, every use of CBB, even CBB_init_fixed, requires a small, fallible allocation to allocate the top-level CBB's cbb_buffer_st. We could embed cbb_buffer_st directly in CBB, but then every child CBB wastes that space, and needs an extra pointer to point back to the cbb_buffer_st. But top-level and child CBBs have disjoint representations anyway. We share a cbb_buffer_st pointer, but it's owning in one case and borrowed in another. Child CBBs have length prefix information, but it's never filed in for a top-level CBB. Make this a sum type, with is_child as the discriminator and a union for the two structures. (Elsewhere I've been trying to get rid of unions, but this isn't using unions for type-punning, so it should valid even in C++. We never access inactive arms.) The implementation gains a few more branches, but now CBB_init_fixed is infallible and allocation-less. I'm hoping this will let us more freely convert functions like UTF8_putc into CBB because we don't need to worry about cleanup or introducing allocations. Change-Id: If0b28cd9e079418f35d5a614058c0aa73658822e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54645 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> 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.
Project links:
There are other files in this directory which might be helpful: