| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
| |
The DLL export issue isn't a problem currently, since we don't explicitly export any symbols from the test dll. This will be an issue in the future though. Additionally, there was a typo in absl_internal_test_dll_contains that caused abseil_test_dll to be empty (and therefore not create a lib file).
PiperOrigin-RevId: 504555797
Change-Id: Ic7b50bcbe704f7c8fd44028071abcf5d6babb2cf
|
|
|
|
|
| |
PiperOrigin-RevId: 504555535
Change-Id: Id40484e9f52c87e9d67def2735ee60481ca50526
|
|
|
|
|
|
|
| |
This broke builds of abseil_test_dll, since CMake can't find the file we incorrectly specified.
PiperOrigin-RevId: 504372451
Change-Id: I6cd5a44f12bb2f473fae2ac920e047e782ae9524
|
|
|
|
|
|
|
|
|
| |
uninitialized array in logging.
It's uninitialized on purpose; we'll write into it through the span.
PiperOrigin-RevId: 504318917
Change-Id: I79835f0190253b8b470b3ca404f3979715f2a718
|
|
|
|
|
|
|
| |
This was tested with https://github.com/protocolbuffers/protobuf/pull/11623 in Protobuf's windows shared library build.
PiperOrigin-RevId: 504294227
Change-Id: I9657197e649a334585bffa2c7bc6340cd2354e84
|
|
|
|
|
| |
PiperOrigin-RevId: 504045295
Change-Id: I110d4573087358e17a719def29e8037adfac6d15
|
|
|
|
|
|
|
|
|
| |
possible.
Const references enforce stronger constraints and are consistent with the standard library signature. There should be no performance loss.
PiperOrigin-RevId: 504043141
Change-Id: I6c4b017665a462fc04e16f425d330fce2c3da227
|
|
|
|
|
|
|
|
| |
Ensure that we know both real low and high stack bounds
when relying on the stack bounds check.
PiperOrigin-RevId: 504003431
Change-Id: I8f6e6b75f5edff233d3cf80285f81b53f9080a0f
|
|
|
|
|
|
|
| |
In the non-dll case, don't set the LNK_LIB variable in the deps loop.
PiperOrigin-RevId: 503854597
Change-Id: Ic57711c1ed95b998e6ca4f27a0a7982ee99595e2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use std::allocator_traits and std::pointer traits.
Note that the reason given in the comments for these implementations was
incorrect. Both of these exist in C++11, but not all compilers had
working implementations, so Abseil backfiled them. All supported compilers
now have working implementations.
https://en.cppreference.com/w/cpp/memory/allocator_traits
https://en.cppreference.com/w/cpp/memory/pointer_traits
Documentation has been updated to recommend the std:: spellings.
Fixes #1366
PiperOrigin-RevId: 503532746
Change-Id: Ia437f65a4c752581195dc582a41831b479d096c6
|
|
|
|
|
|
|
| |
the find isn't inlined but the iterator comparison is.
PiperOrigin-RevId: 503473637
Change-Id: I02b8d95b7a1b738314c4f07a863c7606f822f079
|
|
|
|
|
| |
PiperOrigin-RevId: 503437019
Change-Id: I3630fec690f1472130fef21b16dfcd3c5208aa69
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
END_PUBLIC
absl: relax frame size check in x86 stack unwinding
Currently the unwinder stops whenever it sees a frame >100000 bytes.
There may be such legitimate frames, the default stack size is O(megabytes).
Only do this check if we are not within the thread stack bounds.
The thread stack is assumed to be readable, so the worst thing that can happen
if the large stack frame is actually bogus is that we will add one/few wrong frames and stop.
PiperOrigin-RevId: 503374764
Change-Id: Icabb55d6468b12a42bf026c37c98dbe84977e659
|
|
|
|
|
|
|
|
| |
the earliest supported GCC version according to
https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md
PiperOrigin-RevId: 503337021
Change-Id: Ibc7b2453b7aa30779b76e2a4ad918e39d0efcabe
|
|
|
|
|
|
|
| |
we intentionally test this behavior
PiperOrigin-RevId: 503234578
Change-Id: Ic42c2e55e03843af7a36f99debb5ebcf7baec0fe
|
|
|
|
|
| |
PiperOrigin-RevId: 503229681
Change-Id: I72817b43c547bd142144d0887866c4e26ec09fb2
|
|
|
|
|
|
|
| |
harmonize Base64Unescape and WebSafeBase64Unescape's documentation of padding.
PiperOrigin-RevId: 503178146
Change-Id: Id216044a9f6520653e2fa3a4505ff05eddf55659
|
|
|
|
|
|
|
| |
Fixes #1365
PiperOrigin-RevId: 503160321
Change-Id: I210f194373c3e08a75d68298a8482be5f1f2227c
|
|
|
|
|
| |
PiperOrigin-RevId: 503110285
Change-Id: I59c48b1486386e2db8fb62cf8bfa1a691865f704
|
|
|
|
|
|
|
| |
iterating over collections.
PiperOrigin-RevId: 503088193
Change-Id: Ic1f239f3b0427e0fea1643ec0ce7baff45ad647d
|
|
|
|
|
| |
PiperOrigin-RevId: 502901875
Change-Id: I1c8c097e5c81a9e413692109ebfe0d0b24f50f2e
|
|
|
|
|
| |
PiperOrigin-RevId: 502689876
Change-Id: If75b00e2e257283b60c41411ef7a60dbd7cd8c6d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation can be optimized to not having to perform an ExtendByZero operation.
`RemoveCrc32cSuffix` can simply be implemented as
uint32_t result = static_cast<uint32_t>(full_string_crc) ^
static_cast<uint32_t>(suffix_crc);
CrcEngine()->UnextendByZeroes(&result, suffix_len);
return crc32c_t{result};
Math proof that this change is correct:
`ComputeCrc32c` actually computes the following:
ConditionedCRC(data) = UnconditionedCRC(data) + StartValue(data) + ~0
with:
StartValue(data) = ~0 * x**BitLength(data) mod P
(with `+` being a carry-less add, ie an xor).
``UnconditionedCRC` in the context of this description means: no initial or final xor with ~0 and a starting value of zero - ie the result that `CrcEngine()->Extend` would give you with a starting value of 0.
Given `full_string_crc` and `suffix_crc` (both conditioned CRCs), xoring them together results in:
(1):
full_string_crc + suffix_crc =
UnconditionedCRC(full_string) + StartValue(full_string) + ~0
+ UnconditionedCRC(suffix) + StartValue(suffix) + ~0
Since `+` is carry-less addition (ie an XOR), the two ~0 cancel each other out.
(2)
full_string_crc + suffix_crc =
UnconditionedCRC(full_string) + StartValue(full_string)
+ UnconditionedCRC(suffix) + StartValue(suffix)
We can make use of the fact that:
(3)
UnconditionedCRC(full_string) + UnConditionedCRC(suffix)
= UnconditionedCRC(full_string_with_suffix_replaced_by_zeros).
Ie, UnconditionedCRC("AABBB") + UnconditionedCRC("BBB") = UnconditionedCRC("AA\0\0\0")
Putting (3) into (2) yields:
(4)
full_string_crc + suffix_crc =
UnconditionedCRC(full_string_with_suffix_replaced_by_zeros)
+ StartValue(full_string) + StartValue(suffix)
Using:
(5)
UnconditionedCRC(full_string_with_suffix_replaced_by_zeros)
=
UnconditionedCRC(full_string_without_suffix) * x**Bitlength(suffix) mod P
and putting (5) into (4)
(6)
full_string_crc + suffix_crc =
UnconditionedCRC(full_string_without_suffix) * x**Bitlength(suffix) mod P +
StartValue(full_string) + StartValue(suffix)
Using
(7)
StartValue(full_string) = ~0 * x ** Bitlength(full_string) mod P
and
(8)
StartValue(suffix) = ~0 * x**BitLength(suffix) mod P
Putting (7) and (8) in (6):
(9):
full_string_crc + suffix_crc =
UnconditionedCRC(full_string_without_suffix) * x**(Bitlength(suffix)) mod P
+ ~0 * x ** Bitlength(full_string) mod P
+ ~0 * x ** BitLength(suffix) mod P
Using:
(10)
Bitlength(full_string) =
Bitlength(full_string_without_suffix) +
Bitlength(suffix)
And putting (10) in (9):
(11)
full_string_crc + suffix_crc =
UnconditionedCRC(full_string_without_suffix) * x**(Bitlength(suffix)) mod P
+ ~0 * x ** (Bitlength(full_string_without_suffix) + Bitlength(suffix)) mod P
+ ~0 * x ** BitLength(suffix) mod P
using x**(A+B) = x**A * x**B results in:
(12)
full_string_crc + suffix_crc =
UnconditionedCRC(full_string_without_suffix) * x**(Bitlength(suffix)) mod P
+ [ ~0 * x ** Bitlength(full_string_without_suffix) * x**Bitlength(suffix)] mod P
+ ~0 * x ** BitLength(suffix) mod P
using A mod P + B mod P + C mod P = (A + B + C) mod P:
(this works in carry-less arithmetic)
(13)
full_string_crc + suffix_crc = [
UnconditionedCRC(full_string_without_suffix) * x**(Bitlength(suffix))
+ [ ~0 * x ** Bitlength(full_string_without_suffix) * x**Bitlength(suffix)]
+ ~0 * x ** BitLength(suffix) ] mod P
Factor out x**Bitlength(suffix):
(14)
full_string_crc + suffix_crc = [
x**(Bitlength(suffix)) * [
UnconditionedCRC(full_string_without_suffix)
+ ~0 * x ** Bitlength(full_string_without_suffix)
+ ~0 ] mod P
Using:
(15)
ConditionedCRC(full_string_without_suffix) =
[ UnconditionedCRC(full_string_without_suffix)
+ ~0 * x ** Bitlength(full_string_without_suffix) ] mod P + ~0
=
[ UnconditionedCRC(full_string_without_suffix)
+ ~0 * x ** Bitlength(full_string_without_suffix) + ~0] mod P
(~0 is less than x**32, so ~0 mod P = ~0)
Putting (15) in (14) results in:
full_string_crc + suffix_crc = [
x**(Bitlength(suffix)) * ConditionedCRC(full_string_without_suffix)] mod P
Or:
(16)
ConditionedCRC(full_string_without_suffix) =
(full_string_crc + suffix_crc) * x**(-Bitlength(suffix)) mod P
A multiplication by x**(-8*bytelength) mod P is implemented by `CrcEngine()->UnextendByZeros`.
PiperOrigin-RevId: 502659140
Change-Id: I66b0700d258f948be0885f691370b73d7fad56e3
|
|
|
|
|
|
|
| |
growth runs out.
PiperOrigin-RevId: 502625638
Change-Id: I1c06b2162dbdaaa6a36cea503ac6d07cd157b2e2
|
|
|
|
|
|
|
| |
#1359
PiperOrigin-RevId: 502597369
Change-Id: I5d65ed7e2dbe4b51ebce47f282ead89d91d919cd
|
|
|
|
|
|
|
| |
volatile pointer type testcase to char pointers.
PiperOrigin-RevId: 501781539
Change-Id: I99012cecd960745de8a921b96671cde42e28a3af
|
|
|
|
|
| |
PiperOrigin-RevId: 501644407
Change-Id: Ie98d22e4983cfbd9cad2176925774d624d4702cf
|
|
|
|
|
| |
PiperOrigin-RevId: 501464530
Change-Id: I5a0929a2b88c1c158b1696634a65ffda9c4b8590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several problems with the previous documentation:
* It said it's stable "within the same binary" but not stable "across multiple binary invocations". Those statements contradict each other.
* It said "in the same binary will not produce the same sequence of variates within the same binary", which is repetitive since it says "in the same binary" twice.
* The comments about the seed sequence were not all next to each other, they were split apart by a rand.req.urng comment.
* It implied that process stability is all you get, whereas generally you also get changelist stability.
* It said you can use a seed sequence with SharedBitGen, but you can't.
* It said there is more info in std_seed_seq.h , but there isn't.
PiperOrigin-RevId: 501389708
Change-Id: I5e3dbc3548cc051265b8d004191c23147eccecc3
|
|
|
|
|
| |
PiperOrigin-RevId: 501343076
Change-Id: I12e04a87b9a90951f9b52bd9690cce28d03b0f29
|
|
|
|
|
| |
PiperOrigin-RevId: 501294426
Change-Id: Ic580a2f31b4a98b1dd3eb21f3279fda4cd4a5977
|
|
|
|
|
| |
PiperOrigin-RevId: 501074382
Change-Id: I26a59ee6452855685ffe89469c352e6384060f59
|
|
|
|
|
| |
PiperOrigin-RevId: 501014555
Change-Id: Ie204d307a4e537935a04c0f23bb13532e3c84bc8
|
|
|
|
|
|
|
|
|
| |
Remove duplicate documentation for two variants of Base64EscapeInternal().
Clarify role of base64 char array input (controls web-safe or not).
PiperOrigin-RevId: 500867221
Change-Id: Ie316a7ddd60794e041c5b9b39e9ab5b66ed565a6
|
|
|
|
|
|
|
| |
particular RFC specifications.
PiperOrigin-RevId: 500809781
Change-Id: I34d089343321f7658db8252ad29ff1824e6dbef2
|
|
|
|
|
| |
PiperOrigin-RevId: 500765473
Change-Id: Iaa3f9fdee6c9f4322bc8995b0d381cf1c8cb1349
|
|
|
|
|
|
|
|
| |
This is consistent with the rest of the GTEST_HAS_DEATH usages in
the code and the example in gtest-port.h.
PiperOrigin-RevId: 500740093
Change-Id: I2acc158116b0e8bccc8ab45d75c8059828a4c251
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 500726761
Change-Id: I42fbd4d2d8015e907b3c40417d35be2bbb63085e
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 500401844
Change-Id: I6d0909a8e395c914861dd034824a34737a52d71f
|
|\ \
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 500300819
Change-Id: Iacff97071d158843d687c811b0d78d4ddeba9039
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This also ensures that there is only one definition of
GetArchSpecificEngines by moving the condition to a common place.
PiperOrigin-RevId: 500038304
Change-Id: If0c55d701dfdc11a1a9c8c1b34eb220435529ffb
|
| | |
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 499964205
Change-Id: I45a1d62a5e093921946e7c3c7ab31480252b330e
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CalculateBase64EscapedLenInternal helper method.
Note that output padding is conditional on do_padding.
PiperOrigin-RevId: 499901986
Change-Id: I8c1d28fe372b3e0e2216654db83f949caa297892
|
| |
| |
| |
| |
| |
| |
| | |
This is now available as the public symbol ABSL_UNREACHABLE().
PiperOrigin-RevId: 499578459
Change-Id: Ib36c1826eb733271a6b02e81d6c3d088b255180a
|
| |
| |
| |
| |
| |
| |
| |
| | |
32-bit builds with SSE 4.2 do exist, and these builds do not work
without this patch.
PiperOrigin-RevId: 499498979
Change-Id: I0ade09068804655652c07d0f1ef13554464a1558
|
| |
| |
| |
| |
| |
| |
| | |
Using Damerau-Levenshtein distance to calculate potential candidates to suggest.
PiperOrigin-RevId: 499449034
Change-Id: I805aafefcd0f4f85585ac33a041c15360619c96a
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 499292396
Change-Id: I3c66754169d7d7e304d5b973c0872690b79f59c5
|
|/
|
|
|
|
|
|
|
|
| |
off64_t is not provided without defining _LARGEFILE64_SOURCE on musl
this define is not defined automatically like glibc where it gets
defined when _GNU_SOURCE is defined. Using off_t makes it portable
across musl/glibc and for using 64bit off_t on glibc 32bit systems
-D_FILE_OFFSET_BITS=64 can be defined during build via CXXFLAGS
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|