bzero is hashdefined to memset in strings.h and it
was removed from POSIX 2008.
Bug: http://b/26407170
Change-Id: Ia6d54f0e314dc7f5f3fbad0e9b00344f49f77d43
Currently, reads of ro.* properties are treated differently than
writes of ro.* properties. When writing an ro.* property, we ignore
the "ro." portion of the property, and base the security decision
on the label of the remaining portion.
See e7a9e52740/init/property_service.cpp
line 120-126
For example, for writing, the label associated with
"ro.build.fingerprint" comes from the /property_contexts file
entry:
# ro.build.fingerprint is either set in /system/build.prop, or is
# set at runtime by system_server.
build.fingerprint u:object_r:fingerprint_prop:s0
However, we fail to follow this same special case when sorting
properties into files. Instead, ro.build.fingerprint is assigned
u:object_r:default_prop:s0 instead of u:object_r:fingerprint_prop:s0
Ignore the "ro." portion when sorting properties into files.
This will make reads and writes of properties use the same label.
Bug: 21852512
Change-Id: Ie88ffc6b78b31fc8ddf370ae27c218546fb25a83
Correct the comment, and remove the unused functionality. getauxval(3) does
now set errno to let you know it failed to find anything, but since none of
this function's callers care anyway it seems safer to leave errno untouched
until we actually have a demonstrated need for it.
Bug: https://code.google.com/p/android/issues/detail?id=198111
Change-Id: I232a42dc5a02c8faab94c7d69bef610408276c23
The following arm symbols should be exported by libc.so:
__aeabi_atexit; # arm
__aeabi_memclr; # arm
__aeabi_memclr4; # arm
__aeabi_memclr8; # arm
__aeabi_memcpy; # arm
__aeabi_memcpy4; # arm
__aeabi_memcpy8; # arm
__aeabi_memmove; # arm
__aeabi_memmove4; # arm
__aeabi_memmove8; # arm
__aeabi_memset; # arm
__aeabi_memset4; # arm
__aeabi_memset8; # arm
Bug: https://github.com/android-ndk/ndk/issues/1
Change-Id: I542d1ad023b8aece5dc05a28a9ca549cb51455b4
Also, we're not a debugger.
Also include LD_LIBRARY_PATH and LD_PRELOAD because they would have helped
diagnose a recent issue.
Change-Id: I7237a7236b7140ab49483c02efa705317d07bd3f
This reverts commit 76814a8250.
This differs from the original in fixing the GCC -Werror build:
bionic/libc/bionic/ifaddrs.cpp: In function 'void __handle_netlink_response(ifaddrs**, nlmsghdr*)':
bionic/libc/bionic/ifaddrs.cpp:113:62: error: use of old-style cast [-Werror=old-style-cast]
ifinfomsg* ifi = reinterpret_cast<ifinfomsg*>(NLMSG_DATA(hdr));
This appears to be a GCC bug; the GCC command-line correctly uses -isystem,
and manually adding #pragma GCC system_header doesn't help. So just turn the
warning off for GCC for now. We won't need to worry about building with GCC
soon anyway.
Bug: http://b/26238832
Change-Id: I01615bd335edf11baf487b1c83a9157cd780f4a1
Shared namespaces clone the list of loaded native
libraries from the caller namespace. This allows
classloaders for bundled apps to share already loaded
libraries with default namespace.
Bug: http://b/22548808
Bug: http://b/26165097
Change-Id: I8949d45937fdb38e1f586ff0679003adac0d9dad
(cherry picked from commit e78deef364d952dd1141a2f3067a12060aaf11e6)
Time to dust off the old libcore implementation from gingerbread and add it
to bionic. Unlike the original, this actually looks at both RTM_NEWLINK and
RTM_NEWADDR.
Bug: http://b/26238832
Change-Id: I7bb4b432deb766065b66b9c9ff36ed68249aba82
The BIONIC_ROUND_UP_POWER_OF_2 macro did not have parentheses around
the whole expression. This lead to the wrong value being computed when
used as part of a mathematical expression such as this:
value = BIONIC_ROUND_UP_POWER_OF_2(value) - 1;
This only happens on 64 bit abis.
Change-Id: I6f8afbdaf16fe64a88fa0246d074b3534c9159c1
It actually means "crash immediately". Well, it's an error. And callers are
much more likely to realize their mistake if we crash immediately rather
than return EINVAL. Historically, glibc has crashed and bionic -- before
the recent changes -- returned EINVAL, so this is a behavior change.
Change-Id: I0c2373a6703b20b8a97aacc1e66368a5885e8c51
Under some circumstances, doing a calloc will make sure that the memory
returned will be zero up to the size of the requested size. However, if
there is more usable size than the requested size, that extra part
of the allocation will not be zeroed. This change fixes it so that the
entire usable memory is always zeroed.
Change-Id: I8a66d6767c074023c4ba3568bf2705e1886740fc
