The permitted and search paths should be changed according to VNDK
version for VNDK snapshot. So, {VNDK_VER} value is added in ld.config.txt
file and this value is set through the linker.
If ro.vndk.version is not set, search paths are vndk and vndk-sp as
before.
Bug: 66074376
Test: build & run
Change-Id: I266b66fe1bc95d8925053ef497db11ac0a57c082
I was unable to find a single use of this anywhere, and the networking
folks point out https://tools.ietf.org/html/rfc6093:
"""
5. Advice to New Applications Employing TCP
As a result of the issues discussed in Section 3.2 and Section 3.4,
new applications SHOULD NOT employ the TCP urgent mechanism.
"""
Applications that think they want to do these tricksy things should be
referred to section 3.4, wherein it's noted that these semantics are
effectively dead and it's middleboxes what killed 'em:
"""
3.4. Interaction of Middleboxes with TCP Urgent Indications
As a result of the publication of Network Intrusion Detection System
(NIDS) evasion techniques based on TCP urgent indications [phrack],
some middleboxes clear the urgent indications by clearing the URG
flag and setting the Urgent Pointer to zero. This causes the "urgent
data" to become "in line" (that is, accessible by the read(2) call or
the recv(2) call without the MSG_OOB flag) in the case of those TCP
implementations that interpret the TCP urgent mechanism as a facility
for delivering "out-of-band" data (as described in Section 3.1). An
example of such a middlebox is the Cisco PIX firewall [Cisco-PIX].
This should discourage applications from depending on urgent
indications for their correct operation, as urgent indications may
not be reliable in the current Internet.
"""
Bug: N/A
Test: N/A
Change-Id: I73280db1d803bb7bd93954c13c653fa0cd3daff9
These are still needed for backwards compatibility with code built by old
versions of the NDK, but we don't need to pollute the headers with them.
Also lose the hand-written code for these. The compiler-generated code
is either the same or better, and no new code is calling these functions
anyway.
Bug: N/A
Test: ran tests
Change-Id: Ib01ad9805034433e0105aec882608cc8e6526f78
They're POSIX, and they're implemented in iOS and glibc, but they're
not actually used in any codebase I have access to. They're *defined*
in several places, and some of those places have a handful of tests,
but I couldn't find a single genuine caller.
Bug: N/A
Test: N/A
Change-Id: Id3e2c36183fcff323aa5a2e3a3dabaa8378fae56
std::remove_if moves removed elements to the end, without actually
resizing the collection. To do so, you have to call erase on its
returned iterator.
Test: mma
Change-Id: Iae7f2f194166408f2b101d0c1cfc95202d8bbe63
I'm skeptical about the usefulness of this, but it's in POSIX, it's
in glibc (but not iOS), and it is used in some internal source (test
runners and container code).
Bug: N/A
Test: ran tests
Change-Id: I92c5398f2a679b21a33fba92bc8e67e3ae2eb76f
Surprisingly to me, there are actual uses of `swab` in the codebases
I have available to search, including one with a #ifndef __ANDROID__
around it.
Bug: N/A
Test: ran tests
Change-Id: Ic91b78ae22bb65c346cb46dd38916f48d979abe0
Went through the POSIX spec for the _POSIX* and _XOPEN* constants.
Bug: http://b/32776472
Test: ran tests
Change-Id: I389100dbc7de354eae9056e44b0a7fa8c37374e3
We store a pointer to the long ro. property within the shared property
area, as we know that this pointer will never change locations or be
invalidated and it saves us from needing to allocate arbitrarily sized
storage for the property.
Bug: 23102347
Bug: 34954705
Test: bionic-unit-tests
Change-Id: I9f9147a2f951f20f51e4664c6faf9ff7f6a9502a
This reverts commit 9cb8639b18.
Fixed all the broken builds that were reported to me before this was
reverted.
Test: make checkbuild # kikey960, marlin, aosp_arm64; master and aosp
