Also add a couple of comments in the tests for ease of understanding
when grepping for `__BIONIC__`.
Bug: N/A
Test: N/A
Change-Id: I7833a3ffbcc3badf9cec95f268d11a6d8a5ff9aa
We're still seeing lots of confusion. People do seem to look as far as
the headers, but stop there. So let's try a bit harder to point them in
the right direction.
Also explicitly state that removing _FILE_OFFSET_BITS=64 is the
behavior-preserving fix for compilation problems when upgrading to NDK
r15 or later.
Bug: N/A
Test: N/A
Change-Id: I2d5c65b2fb5cccb9977901e51fea1ad2ccc0fd95
Also simplify trivial one-liners like perror/puts/fputs, and clean up
fread/fwrite slightly.
Fix perror to match POSIX.
Add basic perror and *_unlocked tests.
Bug: N/A
Test: ran tests
Change-Id: I63f83c8e0c15c3c4096509d17421ac331b6fc23d
Historically, Android defaulted to EXPLICIT but with a special case
because SCHED_NORMAL/priority 0 was awkward. Because the code couldn't
actually tell whether SCHED_NORMAL/priority 0 was a genuine attempt to
explicitly set those attributes (because the parent thread is SCHED_FIFO,
say) or just because the pthread_attr_t was left at its defaults.
Now we support INHERIT, we could call sched_getscheduler to see whether
we actually need to call sched_setscheduler, but since the major cost
is the fixed syscall overhead, we may as well just conservatively
call sched_setscheduler and let the kernel decide whether it's a
no-op. (Especially because we'd then have to add both sched_getscheduler
and sched_setscheduler to any seccomp filter.)
Platform code (or app code that only needs to support >= P) can actually
add a call to pthread_attr_setinheritsched to say that they just want
to inherit (if they know that none of their threads actually mess with
scheduler attributes at all), which will save them a sched_setscheduler
call except in the doubly-special case of SCHED_RESET_ON_FORK (which we
do handle).
An alternative would be "make pthread_attr_setschedparams and
pthread_attr_setschedprio set EXPLICIT and change the platform default
to INHERIT", but even though I can only think of weird pathological
examples where anyone would notice that change, that behavior -- of
pthread_attr_setschedparams/pthread_attr_setschedprio overriding an
earlier call to pthread_attr_setinheritsched -- isn't allowed by POSIX
(whereas defaulting to EXPLICIT is).
If we have a lot of trouble with this change in the app compatibility
testing phase, though, we'll want to reconsider this decision!
-*-
This change also removes a comment about setting the scheduler attributes
in main_thread because we'd have to actually keep them up to date,
and it's not clear that doing so would be worth the trouble.
Also make async_safe_format_log preserve errno so we don't have to be
so careful around it.
Bug: http://b/67471710
Test: ran tests
Change-Id: Idd026c4ce78a536656adcb57aa2e7b2c616eeddf
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
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
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
Add all the missing <netdb.h> functions.
Also fix getservbyport to handle a null protocol correctly.
Also fix getservbyname/getservbyport to not interfere with getservent.
Also fix endservent to reset getservent iteration.
Also reduce unnecessary differences from upstream NetBSD sethostent.c.
The servent implementation is still horrific, and we should
probably support protoent too so that debugging tools can use
getprotobyname/getprotobynumber.
Bug: N/A
Test: ran tests
Change-Id: I639108c46df0a768af297cf3bbce857cb1bef9d9
They're marked obsolescent in POSIX, don't clearly mean anything, aren't
portable because the values don't mean anything, and are no-ops in other
C libraries that do "implement" them.
Bug: N/A
Test: N/A
Change-Id: I07342a0a6a5f6616a8432bfea24ed944c7971d27
We have no utmp, and we're ignoring getutxent/setutxent, and endutxent
belongs in the same group.
Bug: N/A
Test: N/A
Change-Id: Ide032960a0f95750f3bb8f2e62a25e5e7d25c7b6
Also start breaking up the monolithic top level README.md, pulling the
32-bit ABI stuff out into its own file, and moving the remaining benchmark
documentation in with the rest of the benchmark documentation.
Bug: N/A
Test: N/A
Change-Id: Ic1b9995e27b5044199ed34883cc0b8faa894df0e
