These are old enough now that the latest devices will have kernels that
support them.
Also add basic doc comments to <sys/mman.h>.
Test: treehugger
Change-Id: I1b5ff5db0b6270f5c374287cac1d6a751a0259f5
FreeBSD, glibc, and musl have all implemented C11 threads at this
point. POSIX is looking at how to align with it. Probably time to jump
on the bandwagon ourselves...
Implemented in the same style as <termios.h> so we can provide this
functionality even on older API levels. This does mean that this is
strictly more expensive than calling pthread functions directly.
Although this isn't in POSIX yet, assume that it's going to be basically
the same as C11 and add the header test anyway. We should revisit this
when POSIX actually adds <threads.h>.
Test: new tests
Change-Id: I8602d67ce71ca7f8ed1529daa0a8ea1feb083dd6
Our strptime was missing `%F`, `%G`, `%g`, `%P`, `%u`, `%V`, and
`%v`. Most of these are already supported upstream (and I've just pulled
their current implementation), but some aren't. We're horribly out of
sync anyway, so I'll upstream the missing pieces and then try to get us
back in sync later.
Test: new tests, but originally found by toybox trying to use %F
Change-Id: Ib1a10801a7a3b9c9189440c3b300109bde535fd9
Jemalloc does not verify that the size parameter is a multiple of
alignment. Fix this since it only went into P.
Fix the unit tests, and fix malloc debug/malloc hooks to handle this
new restrictive behavior.
Bug: 126944692
Test: Ran bionic unit tests.
Test: Ran bionic unit tests with malloc hooks enabled (no new tests fail).
Test: Ran bionic unit tests with malloc debug enabled (no new tests fail).
Test: Ran malloc debug unit tests.
Change-Id: I4d50785928815679c781ca729f998454d76b9192
Originally a BSD extension, now in glibc too. We've used it internally
for a while.
(cherry-pick of e4b13f7e3ca68edfcc5faedc5e7d4e13c4e8edb9.)
Bug: http://b/112163459
Test: ran tests
Change-Id: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Merged-In: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Historically we haven't documented many behavioral changes, but it's
probably useful to record that information before it's lost (even if,
long term, it might be more useful in the man pages or the doc comments).
Bug: N/A
Test: N/A
Change-Id: Iaa4f651fd6576298d848894b61285ef95879deb9
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
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
