We should fall back to GMT if neither the environment variable nor the
system property is set. This is the case if you wipe a WiFi-only device,
because we currently only take the time zone from cell networks.
Bug: http://b/24773112
Change-Id: I90d236d4d492b6562d75021bd312030b91c1e298
Upstream tzcode said "On platforms with tm_zone, strftime.c now assumes it
is not NULL". Which is fine for any struct tm generated by tzcode, but not
necessarily true of a struct tm constructed by arbitrary code. In particular,
Netflix on Nexus Player was failing to start because they format "%Z" with
a struct tm whose tm_zone is null (the other fields are valid, but, yeah,
that's probably not intentional).
glibc takes a null tm_zone to mean "the current time zone", so let's do that
too. (Historically Android would use the empty string, and POSIX doesn't
clarify which of this is the appropriate behavior when tm_zone is null.)
Bug: http://b/25170306
Change-Id: Idbf68bfe90d143aca7dada8607742905188b1d33
When __cxa_thread_atexit_impl.cpp is compiled with clang on arm64,
Android cannot boot up.
BUG: 25662915
Change-Id: If997b544f43e956172ce605d86fe147d42fd39e0
New 3.8 clang/llvm can compile TLS code now.
* For x86_64, still disable clang due to f128 bug.
* For b/25643775, arm and arm64, disable clang in unit tests.
* Fix thread_local_test.cpp to compile with clang and
limit gcc workaround only to arm and aarch64.
BUG: 25643775
Change-Id: Iecd006bf1fc417dbcce2c63343a59c4bf1fa77ea
Root cause:
If start_routine thread exits before pthread_gettid_np is invokded, the "tid" field
will be cleared so that pthread_gettid_np will get "0" (which is cleared by kernel,
due to the flag "CLONE_CHILD_CLEARTID" is set while calling clone system call inside
pthread_create).
Proposed patch:
Use a mutex to guarantee pthread_gettid_np will be invoked and returned before the
start_routine exits
Signed-off-by: Junjie Hu <junjie.hu@mediatek.com>
Change-Id: I22411f1b0f7446d76a0373cef4ccec858fac7018
(cherry picked from commit 4f80102935)
The current comment implies that we only strip sensitive
environment variables on executing a setuid program. This is
true but incomplete. The AT_SECURE flag is set whenever a
security transition occurs, such as executing a setuid program,
SELinux security transition, executing a file with file capabilities,
etc...
Fixup the comments.
Change-Id: I30a73992adfde14d6e5f642b3a1ead2ee56726be
The mremap definition was incorrect (unsigned long instead of int) and
it was missing the optional new_address parameter.
Change-Id: Ib9d0675aaa098c21617cedc9b2b8cf267be3aec4
Including glibc's <libgen.h> will result in the user getting the POSIX
version of basename always, regardless of when it is included relative
to <string.h>. Prior to this patch, our implementation would result in
the one that's included first winning.
Bug: http://b/25459151
Change-Id: Id4aaf1670dad317d6bbc05763a84ee87596e8e59
The original comment implied that Android 32 bit was the only one
using a bad time_t, but it turns out 32 bit glibc has the same time_t
as Android. Update the comment to reflect this reality.
Change-Id: I72cdd2c677a6521f7b43d4695a52fd8fdc3305bd
_signal was static in 64 bit, and hidden on 32 bit. There is no
reason to have this distinction, so make it hidden in all cases.
Change-Id: I09d5d93ac8cab4fe14dc7bdfeb25aa46a3b7413d
