Coming to C23 via WG14 N2630.
This one is a little interesting, because it actually changes existing
behavior. Previously "0b101" would be parsed as "0", "b", "101" by these
functions. I'm led to believe that glibc plans to actually have separate
versions of these functions for C23 and pre-C23, so callers can have the
behavior they (implicitly) specify by virtue of which -std= they compile
with. Android has never really done anything like that, and I'm pretty
sure app developers have more than enough to worry about with API levels
without having to deal with the cartesian product of API level and C
standard.
Therefore, my plan A is "if you're running on Android >= U, you get C23
behavior". My plan B in the (I think unlikely) event that that actually
causes trouble for anyone is "if you're _targeting_ Android >= U, you
get C23 behavior". I don't think we'd actually want to have two versions
of each of these functions under any circumstances --- that seems by far
the most confusing option.
Test: treehugger
Change-Id: I0bbb30315d3fabd306905ad1484361f5d8745935
Coming to C23 via WG14 N2630, and already in glibc.
We're still missing clang support for %b and %B in format string checking,
but it's probably easier to fix this first. (Apparently GCC already has
support because of glibc.)
Test: treehugger
Change-Id: Ie8bfe4630d00c50e1d047d6756a7f799205356db
ualarm(3) was removed from POSIX in 2008, but somehow wasn't included in
the list of such functions (perhaps because it's not inherently useless
like a lot of the other stuff is; it just has a better replacement).
Test: N/A
Change-Id: I0347d3e7f1357bc2acb870f74e9084872c28ca3e
This is mostly copy-pasted from go/clang-fortify-anatomy. Since it
offers extensive documentation on how FORTIFY works in Bionic, having it
also live within Bionic seems quite helpful.
Bug: 235150687
Fixes: 235150687
Test: None
Change-Id: I20145a5ba3155b1c7b3977f9b688320a7fda4ea2
It's a common cause of confusion, and even a brief explanation can be
quite involved, so it's worth having something we can point to (and
something that interested parties might just find via a web search).
Bug: http://b/207248554
Test: treehugger
Change-Id: I4a6d8917baf99a8f7abef05ce852a31ebe048d68
Auto-generate NOTICE files for all the directories, and for each one
individually rather than mixing libc and libm together.
Test: N/A
Change-Id: I7e251194a8805c4ca78fcc5675c3321bcd5abf0a
Since we last touched this file, the Linux kernel has added the missing
API, but time has also moved on enough to make the cost/benefit
unconvincing for Android.
Bug: http://b/156317457
Test: treehugger
Change-Id: I07fa678458ef10d15540b36ab65e0898d2fdadc6
Update the native allocator documentation to include running of this
benchmark.
Move the malloc_benchmark.cpp to malloc_sql_benchmark.cpp and use
malloc_benchmark.cpp for benchmarking functions from malloc.h.
Bug: 137795072
Test: Ran new benchmark.
Change-Id: I76856de833032da324ad0bc0b6bd85a4ea8c253d
The description of memory_replay talks about unzippping the trace
files, but this is no longer necessary. This language has been
updated to reflect this.
Test: NA
Change-Id: Id808f9bd1286284c8de12b19c08eb8677c76dd53
RSS is the real measurement by which an allocator should be measured
since RSS is the real memory consumed by the process. PSS is a shared
value.
For memory_replay, PSS and RSS should be the same, so this didn't really
matter in practice, but it's better to use the correct name of RSS.
Also, add a small section about fragmentation.
Bug: 138394907
Test: NA
Change-Id: Ic6f982f9c4619f452342e7c105818e33b8b85e44
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
This includes tests that a native allocator has to pass, and the ways
to benchmark a native allocator on Android.
Test: NA
Change-Id: I5e1f4b3eea46ee2240e63a487ca3dfabecff81c0
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
I have a script that converts the internal Google Doc to this markdown
file.
Bug: http://b/78026329
Test: review document
Change-Id: I16cfa60f1e480f859eb79cb0e5f0c519f5622cfd
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
Fix a race condition in the example, and add a linearized version to
make it more clear what's going on.
Test: none
Change-Id: Id9158e4fd407b676ef364e7076985de3ad477457
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
