This removes the goofy sizeof/alignof assertion we've been making. That
was a strict aliasing violation. Now CRYPTO_refcount_t is just
CRYPTO_atomic_u32 without any fuss. It also means nothing should include
<openssl/thread.h> because it contains only deprecated symbols.
Bug: 412269080
Change-Id: Icbf98a31d5af2a4dadab3b20a410c10f98061ed7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79569
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
These seem to no longer be needed? Over time we have gotten a bit more
measured about enabling all of MSVC's warnings (MSVC is just not
designed to be used with -Wall), so I'm guessing that's what changed.
Change-Id: If71850136fb83841a423b63bdf65c2d546ba0223
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77887
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We use the standard Apache 2.0 file header, described in "APPENDIX: How
to apply the Apache License to your work."
This was primarily automated by running:
git ls-tree -r --name-only HEAD | xargs go run ./util/relicense.go
See go/boringssl-relicensing-triage for the results of triaging the
output of the tool.
As part of this, switch from taking fiat-crypto under MIT license to
Apache 2.0. (It is licensed under MIT OR Apache-2.0 OR BSD-1-Clause.)
The copyright_summary tool can also be used to confirm we didn't
accidentally drop any copyright lines:
# Run before the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -out /tmp/old.json
# Run after the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -compare /tmp/old.json
Bug: 364634028
Change-Id: I17c50e761e9d077a1f92e25969e50ed35e320c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75852
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The referenced bug notes some ODR warnings in an unspecified
configuration. (Which I can't get AppleClang or GCC 14 to reproduce, at
least.) This is likely due to us switching to C++. The ODR rules in C++
are a little different, but also perhaps the detection is only kicking
in for C++.
Either way, structs in .cc files are generally not intended to leave
that compilation unit. (Unless it's an opaque struct listed in base.h.)
There's no such thing as `static struct` so this change wraps many
structs in .cc files in `namespace {`. There are also lots of structs in
test file. Those are less concerning, but test files should mostly
entirely be in a namespace so this change does that where possible for
test files containing structs.
Bug: 384186552
Change-Id: I6ccf715fbcdc3ea6260b5d5d05f305182b1a9450
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74407
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We should va_end(args_copy), but the function should not va_end(args).
The caller is responsible for that one.
As I understand it, this in benign: in every target we care about,
va_end is a no-op.
Bug: 379096238
Change-Id: I063c775ecd496edc1b5c69c027d1dd9a04f578d1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74088
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This change switches nearly all of BoringSSL to use C++. The public
functions still use the C ABI, and so code written in C can still use
BoringSSL. Also the use of the C++ standard library is minimal and no
run-time requirement for it is intended.
Change-Id: I902d2f51a3c8d6bd0dc4aabe1b192a15d7b788e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72747
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
David Benjamin