The function objects work equally well without them, and the base
classes were wrong for both types:
* HashForEntry: returns size_t but declared to return hash_t
(uint32_t)
* EqualityForHashedEntries: returns bool and takes two parameters but
declared to return hash_t and take one parameter
std::unary_function was deprecated in C++11 and removed in C++17.
Upstream libc++ now removes the type for new-enough C++ dialects.
Bug: http://b/175635923
Test: treehugger
Change-Id: I2ff15c5da6a4e4f71df08c243f8af2f11d8d2b0d
Surprised this isn't breaking anything, so wanted to
make sure it worked.
Bug: 232557259
Test: libutils_test
Change-Id: Iaec47d644c02dc190e397c6f84dcfab4cc76f566
Before, we only did this in sp<> constructors, but we can always make
this check during the initial incStrong.
Since prebuilts call into the existing report race function declared
in StrongPointer.h, we still call this function from RefBase.cpp.
Bug: 232557259
Test: libutils_test
Change-Id: I4080b1869b83ecf655fc9c182b6de768a6358adf
Replaces libbacktrace in CallStack. There is one small behavioral
change, the BuildId data is added to the unwinds.
Bug: 120606663
Test: All unit tests pass.
Test: Run the fuzzer for over an hour without any crashes.
Change-Id: Ic8a4247c515ce0d3cdc4d2cc15167d1948b15fa5
TEMP_FAILURE_RETRY uses typeof which is only allowed by gcc and clang
for GNU dialects. This switches to __typeof__ which is always supported.
Bug: 224644083
Test: m
Change-Id: I96d48d2f0dc5cd9ab903755d93c71c4eb80f7529
Some systems (originally only Windows) define their own
NO_ERROR macro that overlaps with the enumerator from Errors.h.
The enumerator is only defined if the macro was not.
Bug: 224644083
Test: m
Change-Id: Iee0932b5259b3bfcf6494656b27e6e7488319f5c
OkOrFail<status_t> has specialized conversions for Result<int, StatusT>
to avoid ambiguous implicit conversion sequences. Since user conversion
operators sequences can be followed by integral promotion, specializing
for integral types is necessary.
Specialize ResultError<StatusT> so calling code() returns a status_t
instead of a StatusT and message() is implemented even when not carrying
a string.
Eventually, these classes should be combined.
Add equality operators for ResultError<StatusT>.
Bug: 219580167
Test: atest Errors_test.cpp
Merged-In: I14acecfd2aef33c40e79ddb091e2f4af9291d837
Change-Id: Ifb5ed3c2d3452b10901e4aeb19368d873225d9ce
This change provide a specialization of android::base::OkOrFail for
status_t. As a result, a statement whose type is status_t can be used
with OR_RETURN.
The specialization also provides conversion operators to Result<T,
StatusT> where StatusT is a wrapper type for status_t. This allows
OR_RETURN macro to be used in newer functions that returns Result<T,
StatusT>.
Example usage:
\#include <utils/ErrorsMacros.h>
status_t legacy_inner();
status_t legacy_outer() {
OR_RETURN(legacy_inner());
return OK;
}
Result<T, StatusT> new_outer() {
OR_RETURN(legacy_inner()); // the same macro
return T{...};
}
Bug: 209929099
Test: atest libutils_test
Change-Id: I0def0e84ce3f0c4ff6d508c202bd51902dfc9618
Previously, Looper internally kept track of the requests to add fds
using the fd value itself. It used an internal sequence number
associated with each request to add a callback to avoid a situation
where a callback is unexpectedly called. However, since it used the fd
value rather than the sequence number to register events into epoll,
there was still a way where unintended hangups could occur.
This exact sequence of events caused unintended behavior in Looper:
- An fd (FD) is added to the looper.
- Looper registers FD into epoll using its FD number.
- FD is closed.
- A hangup event arrives from epoll_wait while the Looper is polling.
Looper is waiting for the lock to process the callback for FD, because
it is blocked by:
- A new fd is created and added to the looper. Since the lowest number
fd is reused, this new fd has the same value as FD.
- The poll request for Looper is now unblocked, so it looks up the
callback associated with FD to process the hangup.
- Since FD is already associated with the new callback, the new callback
is called unintentionally.
This CL uses the sequence number to register fds into epoll. That way,
when we get a hangup from epoll that is associated with a sequence
number, there is no way an unexpected callback will called.
This CL also adds a test to verify this behavior. Due to the
nondeterministic nature of this multi-thread scenario, the test verifies
this scenario repeatedly. Without the fix in Looper, the test is flaky,
but should never fail after the fix.
Bug: 195020232
Bug: 189135695
Test: atest libutils_test --rerun-until-failure
Ignore-AOSP-First: Topic CL aosp/1799831 has a merge conflict with
internal master, resolved in ag/15613419.
Change-Id: Ib4edab7f2407adaef6a1708b29bc52634f25dbb6
This reverts commit 70d9fb63e6.
Reason for revert: Outstanding usage of this method removed internally
Change-Id: Idcc00ec261aa1d97f11e47abdb08b10a37b5d20f
Test: Local build; treehugger (which I'll manually confirm runs on the appropriate targets)
String16's ctors already handle static strings, so we don't need a
specialized constructor which accepts StaticString16.
Bug: n/a
Test: libutils_test
Change-Id: I93a1ba70d743ff9c73f113d53ffba73cef6adade
String16 is still in use by AIDL compiler. Because String16 is not
noexcept-move-constructible, the C++ compiler will complain when it is
used with non-copyable types (such as ParcelFileDescriptor).
For example, when vector<Foo> is resized, copy-ctor of Foo is called,
which is not available.
parcelable Foo {
String s;
ParcelFileDescriptor[] pfds;
}
By providing noexcept move-ctor for String16, vector<Foo> can be resized
with no problem.
Btw, copy from StaticString16 is specialized for efficiency and move
from StaticString16 don't need to be different from copy.
Bug: 192136980
Test: libutils_test
Change-Id: I13744a2ceebf5781c3ef7f3a04237a6750b0db0a
Fixes a compiler warning for implicit conversion changes from signed
to unsigned which surfaced when refactoring native input libraries.
Add an explicit cast to avoid adding -Wno-sign-conversion compile
flags.
Test: b libsurfaceflinger_unittest
Change-Id: I8866aef7f09ca5173604abe18c586b68bbf12ed6
This function, ironically, is being removed.
Even more amusing, it was never "remove" anyway --- it literally did
the opposite, and removed everything *except* the range you passed to
it, and should probably have been called "keep"!
I'm looking at reimplementing much of libutils, but first I'm improving
test coverage, and literally every test I wrote for this failed. And
then when I fixed the "obvious bugs" in the implementation, I found
there actually were a couple of existing unit tests --- that mostly
served to demonstrate just how counter-intuitive this function was.
Bug: http://b/156999009
Test: treehugger
Change-Id: I41fd85f7c0988070f4039f607d2e57523d862ed9
It's not tested, and it's not used. Also remove the fuzzer which is just
wasting CPU cycles.
This gets us to 100% function coverage, 100% line coverage, and N/A
branch coverage for StopWatch.
Test: treehugger
Change-Id: Ib5e08510ef1046a6f2af3f0b8a1c317a8bb39fd4
Allow LightRefBase to be used with
ANDROID_UTILS_REF_BASE_DISABLE_IMPLICIT_CONSTRUCTION, mainly for
libhwui.
Bug: N/A
Test: libutils_test
Change-Id: I251c874a80f0a069572bc51da45f8f8e74ba6f5b
