This works (by reading /etc/localtime) on NetBSD, but not on Android
since we have no such file. Fix that by using our equivalent system
property instead.
Also s/time zone/timezone/ in documentation and comments. We've always
been inconsistent about this (as is upstream in code comments and
documentation) but it seems especially odd now we expose a _type_ that
spells it "timezone" to talk of "time zone" even as we're describing
that type and its associated functions.
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: I142995a3ab4deff1073a0aa9e63ce8eac850b93d
* Rationale
The question often comes up of how to use multiple time zones in C code.
If you're single-threaded, you can just use setenv() to manipulate $TZ.
toybox does this, for example. But that's not thread-safe in two
distinct ways: firstly, getenv() is not thread-safe with respect to
modifications to the environment (and between the way putenv() is
specified and the existence of environ, it's not obvious how to fully
fix that), and secondly the _caller_ needs to ensure that no other
threads are using tzset() or any function that behaves "as if" tzset()
was called (which is neither easy to determine nor easy to ensure).
This isn't a bigger problem because most of the time the right answer
is to stop pretending that libc is at all suitable for any i18n, and
switch to icu4c instead. (The NDK icu4c headers do not include ucal_*,
so this is not a realistic option for most applications.)
But what if you're somewhere in between? Like the rust chrono library,
for example? What then?
Currently their "least worst" option is to reinvent the entire wheel and
read our tzdata files. Which isn't a great solution for anyone, for
obvious maintainability reasons.
So it's probably time we broke the catch-22 here and joined NetBSD in
offering a less broken API than standard C has for the last 40 years.
Sure, any would-be caller will have to have a separate "is this
Android?" and even "is this API level >= 35?" path, but that will fix
itself sometime in the 2030s when developers can just assume "yes, it
is", whereas if we keep putting off exposing anything, this problem
never gets solved.
(No-one's bothered to try to implement the std::chrono::time_zone
functionality in libc++ yet, but they'll face a similar problem if/when
they do.)
* Implementation
The good news is that tzcode already implements these functions, so
there's relatively little here.
I've chosen not to expose `struct state` because `struct __timezone_t`
makes for clearer error messages, given that compiler diagnostics will
show the underlying type name (`struct __timezone_t*`) rather than the
typedef name (`timezone_t`) that's used in calling code.
I've moved us over to FreeBSD's wcsftime() rather than keep the OpenBSD
one building --- I've long wanted to only have one implementation here,
and FreeBSD is already doing the "convert back and forth, calling the
non-wide function in the middle" dance that I'd hoped to get round to
doing myself someday. This should mean that our strftime() and
wcsftime() behaviors can't easily diverge in future, plus macOS/iOS are
mostly FreeBSD, so any bugs will likely be interoperable with the other
major mobile operating system, so there's something nice for everyone
there!
The FreeBSD wcsftime() implementation includes a wcsftime_l()
implementation, so that's one stub we can remove. The flip side of that
is that it uses mbsrtowcs_l() and wcsrtombs_l() which we didn't
previously have. So expose those as aliases of mbsrtowcs() and
wcsrtombs().
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: Iee1b9d763ead15eef3d2c33666b3403b68940c3c
At least one person wasn't entirely convinced by our existing riscv64
documentation, and there was an error in the 32 vs 64 section.
Test: N/A
Change-Id: Iaa08b8f4b5a5506a4ade15f81e17325185036a07
Nothing to see here --- you'll want to keep using POSIX clock_gettime()
and clock_getres() instead. But portable code might use this eventually,
and it's trivial, so let's add it anyway.
(The whole "zero as an error return" precluding the direct use of
Linux's CLOCK_ constants is what really makes this a terrible API ---
we're going to have to add explicit translation any time they add a
new base.)
Test: treehugger
Change-Id: Iddb6cbe67b67b2b10fdd8b5ee654896d23deee47
The recent header nullability additions and the corresponding source
cleanup made me notice that we're missing a couple of actions that most
of the other implementations have. They've also been added to the _next_
revision of POSIX, unchanged except for the removal of the `_np` suffix.
They're trivial to implement, the testing is quite simple too, and
if they're going to be in POSIX soon, having them accessible in older
versions of Android via __RENAME() seems useful. (No-one else has shipped
the POSIX names yet.)
Bug: http://b/152414297
Test: treehugger
Change-Id: I0d2a1e47fbd2e826cff9c45038928aa1b6fcce59
At the time I added <stdio_ext.h>, I just added what was on the man
page (which matched glibc), not realizing that musl and glibc had
slightly different functionality in their headers.
The toybox maintainer came up with a legitimate use case for this, for
which there is no portable workaround, so I'm adding it here. I'm not
adding the other functions that are in musl but not glibc for lack of a
motivating use case.
Bug: http://lists.landley.net/htdig.cgi/toybox-landley.net/2022-April/020864.html
Test: treehugger
Change-Id: I073baa86ff0271064d4e2f20a584d38787ead6b0
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
