* 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
wfN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to a fastest minimum-width integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to a fastest minimum-width integer type argument with a width of N bits. All fastest minimum-width integer types (7.22.1.3) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: Iaa1f6d87251144de0b763672ca93f23272880ad1
Strictly the _doc comment_ is correct, but the names of the parameters
are the wrong way round. (Although iconv_open() follows the usual C
tradition of "destination first", iconv() itself doesn't, so these
functions are inherently confused/confusing.)
Bug: https://github.com/android/ndk/issues/1895
Test: N/A
Change-Id: Iafc9bd630ece1d3c55986b04bb9a99c477716530
To enable experiments with non-4KiB page sizes, introduce
an inline page_size() function that will either return the runtime
page size (if PAGE_SIZE is not 4096) or a constant 4096 (elsewhere).
This should ensure that there are no changes to the generated code on
unaffected platforms.
Test: source build/envsetup.sh
lunch aosp_cf_arm64_16k_phone-userdebug
m -j32 installclean
m -j32
Test: launch_cvd \
-kernel_path /path/to/out/android14-5.15/dist/Image \
-initramfs_path /path/to/out/android14-5.15/dist/initramfs.img \
-userdata_format=ext4
Bug: 277272383
Bug: 230790254
Change-Id: Ic0ed98b67f7c6b845804b90a4e16649f2fc94028
Although the existing annotations were strictly true (see
https://github.com/android/ndk/issues/1888#issuecomment-1581773348 for
the gory details), given the Play Store requirement that 32-bit code
must have a 64-bit version, it's not obviously useful to offer a
function for 32-bit before 64-bit.
Test: treehugger
Change-Id: I8ca11b874c26dfaa632690f510cb5409d95012e9
wN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to an integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to an integer type argument with a width of N bits. All minimum-width integer types (7.22.1.2) and exact-width integer types (7.22.1.1) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: I595fd2ac7bc40d9fb7f1935b39933a6cc068eeff
Discussion of this during my recent minor cleanup convinced me that we
should just remove __RENAME_LDBL. There's no obvious benefit to being
able to build something for 32-bit if you can't build the same code for
64-bit, given that most new hardware (and entire verticals such as Auto)
are 64-bit-only, and the Play Store requires any app with 32-bit code to
also ship 64-bit code.
Test: treehugger
Change-Id: I1c5503b968ca66925d7bd125bd3630c41ec1bfd0
Now the NDK doesn't support API levels below 21, we don't actually need
the different arm32 vs x86 annotations. In general we haven't been
removing this historical information because it might be interesting to
someone, and there's no real reason to remove it, but we've had
versioner bugs recently with these more complex cases.
Test: treehugger
Change-Id: I9460109a2648b9d05d7e21e397935293d3fea8eb
