This change lets android::base::ScopeGuard be useful in STL containers
(e.g. std::vector<android::base::ScopeGuard<std::function<void()>>>). It
also provides perfect forwarding for android::base::make_scope_guard.
Bug: 34764308
Test: libbase_test
Change-Id: I7d1e5494b0f0695763cff0700efdb9ec18ae85c8
Allow the default tag (the program name) to be overwritten.
Bug: 34867873
Test: m
Test: logging_test
Test: manual
Change-Id: I4ef32bad413a7cc82e46ce16a2f26212925964b1
Windows build of adb is broken because of the lack of
std::chrono_literals and for an implementation of
android::boot_clock::now().
Test: make -j vts
Bug: 72941624
Change-Id: Ie65fed098633eb45a94ea553de6903f8d55fc5b2
If LOG_TAG was not defined, falling back to a default
behaviour (using binary name).
Bug: 35361699
Test: manual
Change-Id: I209a6ebaf0df882f98642f6d1831766cb296c951
We should have done this from the beginning. Thanks to Windows, we're not
going to be able to switch libbase over to std::string_view any time soon.
Bug: N/A
Test: ran tests
Change-Id: Iff2f56986e39de53f3ac484415378af17dacf26b
Add some helper macros that perform regex string matching to
<android-base/test_utils.h>.
Test: libbase_test32/64 on host
Change-Id: I1b0f03dc73f8b4fdfb8ac6c75d59ef421e0e9640
This reverts commit 4ef5011a7b.
Reason for revert: Breaks an internal mocking case that cannot be changed.
Test: m
Change-Id: I83f9338bde02eb2b45b3e52b66ef78490ddbeeda
In most reasonable cases, this is actually a bug. So delete the
operator overload and let the compiler complain.
Test: m
Change-Id: I7d66ec2f33cc46588b6f549876241871f19ce995
Some tests may create a File* by calling fdopen() on the temp file's
fd. We should release the ownership of fd in this case to avoid the
double close.
Bug: 65430057
Test: libbase unit tests pass
Change-Id: I54fcce2029f9a574f53afdbdda737ee58620c73a
Clang's assert_capability and assert_shared_capability annotations are
nonfunctional until https://reviews.llvm.org/rL309725 is relanded and
makes its way into our toolchain. Work around this by using the
equivalent assert_lock and assert_shared_lock.
Bug: http://b/64226736
Test: manual
Change-Id: I40711f162ea1d492f1e0b3eff88bf6ae6d995e2f
The use of ReadAtOffset is meant to allow concurrent access
to the zip archive once it has been loaded. There were places
where this was the case, and some places that did a seek + read
combination, which could lead to data races.
NOTE: On Windows, we are not using pread as the implementation of
ReadAtOffset, therefore the guarantees on Windows are weaker.
On Linux, pread allows the file descriptor to be read at a specific
offset without changing the read pointer. This allows inherited fd's
and duped fds to be read concurrently.
On Windows, we use the ReadFile API, which allows for an atomic seek +
read operation, but modifies the read pointer. This means that any mix
use of ReadAtOffset and Read will have races. Just using ReadAtOffset is
safe.
For the Windows case, this is fine as the libziparchive code now only
uses ReadAtOffset.
Bug: 62184114
Bug: 62101783
Test: make ziparchive-tests (existing tests pass)
Change-Id: Ia7f9a30af2216682cdd9d578d26e84bc46773bb9
* Update android::base::utf8::open/unlink to support Windows long
paths
* Add android::base::utf8::fopen, also with support for Windows long
paths
* Upcoming CLs will add additional APIs to support additional use cases
Test: Added tests to utf8_test
Bug: 38268753
Change-Id: If72af327f3487766f5370a2f43ee9cabd4a8a810
::android::base::GetMinimumLogSeverity() is defined externally, so the
static analyzer was allowed to assume that we continue executing after a
LOG(FATAL).
I manually audited all of the code I have access to, and the only
"change the minimum log severity" statements I can see keep FATAL
enabled (...and continuing after a FATAL is highly sketchy to me
anyway).
(I'm sure I tested this at some point in making the previous patch. I
probably broke it in a refactor before sending it out for review; my
bad. :) )
Bug: None
Test: m without the static-analyzer builds; m with it yields fewer
false positives.
Change-Id: I216cd2034e1daa8d6f6c5e776f64b4cce88bb938
This helps us have less false-positives.
We do this instead of `#undef NDEBUG`, since undefing NDEBUG actually
gave us more false-positives (...and build breakages) than simply
leaving it defined.
Bug: None
Test: Ran the static analyzer across internal master. 213 fewer warnings
(15 Medium, 2 Low, the remainder are 'Analyzer'). All of the dropped
warnings I audited were false-positives. It adds ~3 Tidy warnings.
Change-Id: Ibedab60ca7e9d2b0772896222b83d2e7ab064afe
Two small changes in one:
- `foo || for (;;abort()) bar();` isn't valid C or C++, since for is a
statement. We need an expression instead.
- we'll now treat everything after LOG(foo) as unreachable in the
static analyzer, as long as we can prove at compile-time that
foo == FATAL.
The impact of this, running across internal master, is that we see ~50
fewer medium/high-severity false positives from clang-tidy. We see 15
new complaints about unreachable code (at the "tidy" severity), but all
of them are harmless AFAICT (e.g.
switch (foo) {
// ...
default:
LOG(FATAL) << "Unhandled case!"; // or CHECK(false);
break; // clang-tidy: unreachable break.
})
(Some of the macros were forcibly formatted by the clang-format hook)
Bug: None
Test: Ran
`DEFAULT_GLOBAL_TIDY_CHECKS=clang-analyzer*,-clang-analyzer-alpha* m`;
stared at warn.py output.
Change-Id: Ie984eda0481afad4274b9def7c61ba777cfa289a
boot_clock was previously returning zero on any platform that doesn't
define __ANDROID__, including host bionic. Instead of returning a bogus
value, just hide it on non-Linux platforms.
Bug: http://b/37758947
Test: libbase_test32/64 on linux
Change-Id: I96e1d8b92dc44c6308408900cf0d27e1e7db5569
Use this for bootstat and init. This replaces the custom uptime parser in
bootstat.
This is a reland of aosp/338325 with a stubbed implementation for Darwin.
This change also has clang_format fixes (automatic).
Bug: 34352037
Test: chrono_utils_test
Change-Id: I72a62a3ca1ccfc0a4ccc6294ff1776c263144686
std::chrono doesn't handle integer overflow, so using
std::chrono::milliseconds::max() to indicate an infinite timeout is
not handled well in the current code. It causes an 'absolute_timeout'
earlier in time than 'now' and causes the associated WaitForProperty*
functions to return immediately.
Also, any duration_cast from relative_timeout to nanoseconds would
cause the same issue, as it would overflow in the conversion and
result in an invalid results.
This change prevents any duration_casts of relative_timeout to
nanoseconds and replaces the logic to wait on an absolute timeout with
logic that compares the time elapsed to the provided relative timeout.
This change also includes a test that std::chrono::milliseconds::max()
does not return immediately and that negative values do return immediately.
Test: Boot bullhead + libbase_test
Change-Id: I335bfa7ba71e86c20119a0ed46014cad44361162
- unlike base::WaitForProperty, which waits for specific value to
be set, this one only waits until the property is created.
bug: 35178781
Test: added unit test
Change-Id: Idbf98c2152fe768357302f6b69310c55305f5d54
Tests will often want to get the executable directory in order to
find test data.
Test: out/host/linux-x86/nativetest64/libbase_tests/libbase_tests
Change-Id: Ica9d211bcd039fcf83a22fd494816abd01b97aa3
adb already provides an implementation of dirname and basename that
take and produce std::strings, move it into libbase so it can be
used in the implementation of GetExecutableDirectory.
Test: out/host/linux-x86/nativetest64/adb_test/adb_test
Test: out/host/linux-x86/nativetest64/libbase_test/libbase_test
Test: adb shell /data/nativetest64/libbase_test/libbase_test64
Change-Id: Ideb1627607b14562121316d4ed27fa6fb0930684
Bionic has <sys/endian.h>, glibc <endian.h>, and macOS and Windows have
nothing. This has often been annoying.
Bug: N/A
Test: new tests
Change-Id: I2a40c570df6a9bb30607ace1af653265938cc4b8
Elliott Hughes