android: Recognize Bionic’s semantics for strerror_r() In previous versions of POSIX, the claim goes, the specification of strerror_r() was ambiguous, and it was unclear whether it returned an error number on failure, or returned nonzero while setting errno to an error number. The standard, if it ever was actually ambiguous on this point, no longer is. The former behavior is required, but that doesn’t change the fact that noncompliant libraries like Bionic continue to implement the latter. https://android.googlesource.com/platform/bionic/+/26bc9c64d5b0cad921e3070a4f94fa04e1077d90/libc/bionic/strerror_r.cpp#52 Adapt to Bionic’s quirk: recognize both failure mechanisms by treating positive return values as error numbers, and negative return values as failure with the error number in errno. Valid error numbers are always positive, and Bionic returns -1 on failure. Chromium has an unnecessarily complex way of achieving the same behavior. This does not affect the use of strerror_r() with glibc, which exposes yet another distinct and nonstandard interface. Bug: crashpad:30 Change-Id: I5c0fe5d7631d224a02d3d3d19457d953422945a8 Reviewed-on: https://chromium-review.googlesource.com/459138 Reviewed-by: Scott Graham <scottmg@chromium.org>
This is mini_chromium, a small collection of useful low-level (“base”) routines from the Chromium open-source project. Chromium is large, sprawling, full of dependencies, and a web browser. mini_chromium is small, self-contained, and a library. mini_chromium is especially useful as a dependency of other code that wishes to use Chromium’s base routines. By using mini_chromium, other projects’ code can function in a standalone environment outside of Chromium without having to treat all of Chromium as a dependency. When building as part of Chromium, those projects’ code can use Chromium’s own (non-mini_chromium) base implementation.
Code provided in mini_chromium provides the same interface as the equivalent code in Chromium.
While it’s a goal of mini_chromium to maintain interface compatibility with Chromium’s base library for the interfaces it does implement, there’s no requirement that it use the same implementations as Chromium’s base library. Many of the implementations used in mini_chromium are identical to Chromium’s, but many others have been modified to eliminate dependencies that are not desired in mini_chromium, and a few are completely distinct from Chromium’s altogether. Additionally, when mini_chromium provides an interface in the form of a file or class present in Chromium, it’s not bound to provide all functions, methods, or types that the Chromium equivalent does. The differences noted above notwithstanding, the interfaces exposed by mini_chromium’s base are and must remain a strict subset of Chromium’s.
Crashpad is the chief consumer of mini_chromium.
Mark Mentovai
mark@chromium.org