The libcs we use don't need these any more (if they ever did), and we
were setting these globally in the build system anyway.
Also remove the -D_LIBCPP_ENABLE_CXX17_REMOVED_BINDERS from versioner
which doesn't seem needed any more either.
Test: treehugger
Change-Id: I9fb225b085906a02918c5847401d6c59f7779581
BYPASS_INCLUSIVE_LANGUAGE_REASON="man" refers to manual not person
Bug: 318749472
Test: atest pthread on MTE enabled device
Test: atest memtag_stack_dlopen_test on MTE enabled device
Test: manual with NDK r26b built app with fsanitize=memtag-stack
Change-Id: Iac191c31b87ccbdc6a52c63ddd22e7b440354202
This CL is created as a best effort to migrate test targets to the new Android ownership model.
It is based on historical data from repository history and insights from git blame.
Given the nature of this effort, there may be instances of incorrect attribution. If you find incorrect or unnecessary
attribution in this CL, please create a new CL to fix that.
For detailed guidelines and further information on the migration please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: Ie36b2a3245d9901323affcc5e51dafbb87af9248
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I0a63faa8ca359592a29d7bca1a40ecd94fd50044
(cherry picked from commit 7506c37386)
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
(This is the sys_vfs_test equivalent of the earlier change made to
sys_statvfs_test.)
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I3c6f784d1e348bf1be3a102d1dd6336c33d0b2db
(cherry picked from commit 1b48afbc66)
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
(This is the sys_vfs_test equivalent of the earlier change made to
sys_statvfs_test.)
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I3c6f784d1e348bf1be3a102d1dd6336c33d0b2db
Obviously stack MTE conflates with the stack protector test. It doesn't
conflate with heap MTE (which we're expecting to push more broadly as
part of the -eng build), and so we want to keep this test working under
heap-mte scenarios as well.
Hence, the check-if-stack-variable-is-tagged test, and only under that
case, we skip.
Test: atest bionic-unit-tests on a fullmte device (with stack MTE turned
back on and the new compiler).
Bug: 320448268
Change-Id: I2ecee8a7c46416883235bf5c4ee2de9408047829
This reverts commit 4c5eeb8346 in main,
where we have the newer tzcode and so can pass the stricter test.
Bug: http://b/307680874
Test: treehugger
Change-Id: I28a6f423815655a59fb503230e50a7b618b0349a
As long as 2024Q1 is using Android 14's CTS, Android 14's CTS needs to
work with both. That doesn't make much sense for this test of a bug fix,
so just disable it.
Bug: http://b/307680874
Test: treehugger
Change-Id: Ic1bea5d0404c91279a025ac97b521f07e4d2d387
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
Bug: http://b/319590754
Test: treehugger
Change-Id: I0a63faa8ca359592a29d7bca1a40ecd94fd50044
gtest's Message class has a special handler for operator<< of wchar_t*
to convert it to UTF-8, but it doesn't have one for a single wchar_t or
for a char16_t* string. It delegates these to std::stringstream, which
as of a libc++ upgrade, deletes its operator<< for char16_t and
wchar_t. See wg21.link/p1423r3.
Bug: http://b/175635923
Test: m MODULES-IN-bionic
Change-Id: I8307663b72855cfc0b91d7f63993f1f6fe028b8e
What's important is that we name the flag. It doesn't really matter
whether you have the better message that will be in Android 15. As long
as 2024Q1 is using Android 14's CTS, Android 14's CTS needs to work with
both.
Bug: http://b/307680874
Test: treehugger
Change-Id: I8c50707e1dfd6b40e6ced887ae105508c6339989
As long as 2024Q1 is using Android 14's CTS, Android 14's CTS needs
to work with both. That doesn't really seem practical for these tests,
so just disable them.
Bug: http://b/307680874
Test: treehugger
Change-Id: Iab4085ce1be1b0e00a6714eaf3008787e29e7e7b
builds
Use a soong config var to control if we should use a large sys prop node
size. Node in prop_area.cpp, the PA_SIZE is controlled by a macro flag.
This macro flag is passed in as a compiler flag which is then added when
the soong configure variable (large_system_property_node) is true.
The sooong configure variable is then backed by a build system flag
defined in build/release/build_flags.scl. The value of this flag is then
determined by different release configurations. Only internal build
release configuration would set this flag to true.
Bug: b/316932568
Change-Id: Ibe2ffda9155246f2217aaa0e7d589ed7effec311
We've updated the corresponding glibc headers so we don't need these
hacks any more.
Bug: http://b/318541070
Test: treehugger
Change-Id: Ic1974f30f9edb2589cc93041822706bc89909882
This reverts commit 46cce48995.
Reason for revert:
Will put a change behind flags to bump storage to 1Mb for internal build only. AOSP code does not need to be changed. The change will be only made to git_main.
Change-Id: If3484d0e56f4c3d8fc729f55744c2d8ebdd13b11
While aconfig flag storage is being migrated to its own dedicated
storage, we need to provide some relief to the current flag users which
are running into storage capacity limit of system property. Currently
system property by default allocates a file of 128Kb for each storage
node. Bump it to 256Kb for now.
Bug: b/316037066
Change-Id: I8b0b58733f362c3789ec92ae09ee589c7c1b72c6
Benchmark added to test an optimization I'll send round next, test added
when an even bigger refactoring (as part of a more interesting
optimization) broke strtol() in a way the strtol() tests didn't notice.
Test: treehugger
Change-Id: Ic974900021107938dbbbe98648960adb102d9595
The sysconf_SC_ARG_MAX test was failing because it didn't
handle the case for 16k. After fixing the test case, it will
handle 4k/16k page sizes and fail when there is another page
size.
Bug: 315174209
Test: atest -c bionic-unit-tests-static
Change-Id: Ie24a79be9d6790a1243be48d39f67acda485c37d
These were added because the tests wouldn't build without them, but they
do now.
Bug: http://b/132640749
Test: treehugger
Change-Id: Idc0aff08ce461bde5ed2cd816f04dcdef5d7af5d
Fix the pthread test cases to support 4k/16k page sizes.
Bug: 315174209
Test: atest -c bionic-unit-tests-static
Change-Id: Ie364e756120c396144f20372cac8239eed6c7bd8
This is now the default.
I've left the fuzzer workaround in for now, but we can come back and see
whether the fuzzer library has actually switched.
Test: treehugger
Change-Id: Ia3a09738396bfe915ceabec4a6019f4cedb0f39c
Calling free() during system property init results in premature
allocator initialization. This has been fixed with a Scudo change in
https://r.android.com/2853684. This patch extends MemtagNoteTest to
verify that there are no stray PROT_MTE mappings when MTE is not
enabled in the binary.
Test: adb shell setprop arm64.memtag.bootctl memtag
adb reboot
bionic-unit-tests --gtest_filter=MemtagNoteTest.SEGV/*
Bug: 309698651
Change-Id: I6c7733d8799537d898c97b00d494ce6591cf44d9
This reverts commit f71ee5adb7.
Reason for revert: linker crash in soinfo::apply_relr_reloc
Bug: 314038442
Change-Id: Ib2415519e37d6b2acb30f50afa6c45391e2a4b70
This way, callees don't need to worry about whether or not their
reference to __riscv_hwprobe() has been resolved before their ifunc
resolver is called.
This matches the current glibc proposal from rivos.
Test: treehugger
Change-Id: I0d5244aa837d0d1f0e6bd7d22091dfedb8a55bdb
This test comes in two flavours: a prebuilt, and one from source (which is used
to generate the prebuilt). For now, the in-tree prebuilt compiler isn't
new enough to actually build binaries with proper MTE globals support,
so I've provided prebuilts using a tip-of-tree compiler. Thus, the MTE
globals support in the linker can be experimented on, tested, and
(hopefully) submitted while not being blocked on the toolchain roll.
You can see the binaries have MTE globals by grabbing a tip-of-tree
compiler, and running 'llvm-readelf --memtag <bin>'.
Bug: N/A
Test: atest bionic-unit-tests --test-filter=*Memtag*
Change-Id: I2fc4fc9d1c6ddd16c2204dd728d4ebe463928522
... to make sure that stores to the same locations are harder to
eliminate.
Also ensure that reader gets a chance to run by sleeping if necessary.
Bug: 308744279
Test: atest stdatomic
Test: Check that we don't usually sleep.
Change-Id: Iddab2a109525f96e065ac8331f227baa08dd8e22
The bionic benchmarks set the decay time in various ways, but
don't necessarily restore it properly. Add a new method for
getting the current decay time and then a way to restore it.
Right now the assumption is that the decay time defaults to zero,
but in the near future that assumption might be incorrect. Therefore
using this method will future proof the code.
Bug: 302212507
Test: Unit tests pass for both static and dynamic executables.
Test: Ran bionic benchmarks that were modified.
Change-Id: Ia77ff9ffee3081c5c1c02cb4309880f33b284e82
msgsnd() takes the following arguments:
1. msqid: the message queue ID
2. msgp: a pointer to a struct whose first member is the message
type (long) and the second the message itself (char array).
3. msgsz: the size of the message
4. msgflg: optional flags
sys_msg.smoke does not correctly specify msgsz, as it provides the
size of the whole struct instead of its message (data) member.
sys_msg.msgsnd_failure does not provide a pointer to a full struct
as msgp. In both cases, this results in the kernel reading garbage
on the stack.
Fix both issues by providing the appropriate size and struct
pointer.
Test: run bionic-tests --gtest_filter=sys_msg.*
Change-Id: Iaa005e259d3ecfa28484dd66222ed6c4584ffc08
We were copying the data fine, but the return value was one vector
length too far (but also not taking into account the actual number of
bytes in the last transfer).
Also move the stpcpy() tests to EXPECT_EQ() so we get all the details
of the failure at once.
Test: treehugger
Change-Id: I76bf02c8a31f40722acb7c9fd8e301d50e405bf8
The zygote cannot have visiblity to LIBC_PLATFORM methods. Therefore,
move __system_properties_reload to LIBC, and rename it
__system_properties_zygote_reload, and indicate in comments that it
should not be used by non-zygote apps
Bug: 291814949
Test: atest CtsBionicRootTestCases
Change-Id: Iee8fa0c76b740543c05a433393f2f4bef36d6d3d
I was re-reading this comment and thought I'd gotten my interpretation
backward, but it's actually just very nuanced. Elaborate a bit so I
hopefully don't reinterpret this again in a few more months.
Bug: None
Test: None
Change-Id: I8ca444f2fb143c46e6068f349e9f5eb574fc4b31
Instead of the hardcoded PAGE_SIZE 4096 macro, use the
real system page-size as queried from the auxillary vector.
Bug: 277272383
Bug: 300367402
Test: atest -c bionic-unit-tests
Change-Id: I2f1ad1b431e36ef45e9f53f713ced6b06e0d4f70
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Create a second set of system properties, that can be overlaid over the
real ones if necessary, for appcompat purposes.
Bug: 291814949
Ignore-AOSP-First: Aosp -> internal merge conflict
Test: manual, treehugger, system_properties_test
Change-Id: I541d3658cab7753c16970957c6ab4fc8bd68d8f3
Merged-In: I884a78b67679c1f0b90a6c0159b17ab007f8cc60
The first app developer (we know of) that hit this didn't understand
what it was trying to tell them.
Before:
FORTIFY: fcntl(F_SETFD) passed non-FD_CLOEXEC flag: 0x801
After:
FORTIFY: fcntl(F_SETFD) only supports FD_CLOEXEC but was passed 0x801
Bug: https://issuetracker.google.com/304348746
Test: treehugger
Change-Id: I8522e851d8f74c91152ebae68b083b5272d49255
Remove tests of implementation details rather than the CFI
functionality itself. In particular, CFI is designed to protect against
invalid calls to executable code, whereas heap memory is covered by page
protection.
Bug: http://b/298741930
Test: treehugger
Change-Id: Ib7f8af283b4c0001da8fa80a1b281bdc4c50af51
Hopefully this is totally unambiguous and non-confusing output:
```
Expected equality of these values:
Errno(22)
Which is: EINVAL
Errno((*__errno()))
Which is: ENOSYS
```
Test: treehugger
Change-Id: Iefe6a8a6447e76681c18256d2713e2c527081c75
strerrordesc_np() isn't very useful (being just another name for
strerror()), but strerrorname_np() lets you get "ENOSYS" for ENOSYS,
which will make some of our test assertion messages clearer when we
switch over from strerror().
This also adds `%#m` formatting to all the relevant functions.
Test: treehugger
Change-Id: Icfe07a39a307d591c3f4f2a09d008dc021643062
The close_range() test in particular has been confusing a lot of
partners. I think the sys_epoll_test.cpp idiom is the clearest of the
ones in use, so let's use that everywhere. (I haven't actually touched
the SysV IPC tests, because if we do touch them, _deleting_ them --
since all those syscalls are not allowed on Android -- is probably the
change to be made!)
I'm on the fence about factoring this idiom out into a macro. There
should never be too many of these, and we should probably be removing
them? Is anyone still running the current bionic tests on 4.3 kernels
without membarrier(2), and if they are --- why?!
For now though, I haven't removed any of our existing tests; I've just
moved them over to the sys_epoll_test.cpp style.
Test: treehugger
Change-Id: Ie69a0bb8f416c79957188e187610ff8a3c4d1e8f
We've talked about this many times in the past, but partners struggle to
understand "expected 38, got 22" in these contexts, and I always have to
go and check the header files just to be sure I'm sure.
I actually think the glibc geterrorname_np() function (which would
return "ENOSYS" rather than "Function not implemented") would be more
helpful, but I'll have to go and implement that first, and then come
back.
Being forced to go through all our errno assertions did also make me
want to use a more consistent style for our ENOSYS assertions in
particular --- there's a particularly readable idiom, and I'll also come
back and move more of those checks to the most readable idiom.
I've added a few missing `errno = 0`s before tests, and removed a few
stray `errno = 0`s from tests that don't actually make assertions about
errno, since I had to look at every single reference to errno anyway.
Test: treehugger
Change-Id: Iba7c56f2adc30288c3e00ade106635e515e88179
Change our handful of `constexpr static`s to the much more common
`static constexpr`. It's easier to "follow existing style" when there
aren't two existing styles to copy from, and all else being equal,
"majority wins" :-)
Test: treehugger
Change-Id: Ifbf0f62ab84c9450bf9c2e49e96915c126fd20c4
A clang update enabled -Wreorder-init-list by default. Since it doesn't
provide any benefit to the bionic code, disable the warning.
Test: Builds without warnings.
Change-Id: I5891527ef532b59dc2a02b39a5896112411d21f5
Musl doesn't have the _SC_LEVEL?_?CACHE_SIZE sysconf macros.
Bug: 257334542
Test: m USE_HOST_MUSL=true host-native
Change-Id: I42e65daa9169e129059ddde5eee487ea51e6f143
When used in an ifunc resolver, errno@plt won't be available. This is
the API the rivos folks contributing to glibc are leaning towards, for
the same reason. Hit by the berberis folks because they don't implement
the syscall so they were trying to set errno to ENOSYS.
Tested by looking at the generated assembler, and also disabling the
vdso (since on actual systems, this will go via the vdso).
Test: treehugger
Change-Id: Ie2779110f141f20efe97cb892fbdefd808b5339b
musl already added tcgetwinsize() and tcsetwinsize(), but I didn't
notice.
Trivial single-line inlines added to a header that's already written
that way.
Test: treehugger
Change-Id: Iac95ea6a89f3872025c512f7e61987b81d0aafa7
This is a bit disappointing. I'd not implemented this in the past
because it wasn't available on all platforms, and -- although the
riscv64 implementation was just a cool optimization -- I thought that
the /sys stuff was actually portable, until I ran it on arm64 hardware.
So here we have getauxval() for riscv64, /sys for x86-64, and our best
guess based on ctr_el0 for arm64.
Bug: http://b/294034962
Test: ran tests on the host, an arm64 device, and riscv64 host and qemu
Change-Id: I420b69b976d30668d4d2ac548c4229e2a4eafb20
I've also added doc comments for everything in <sys/epoll.h>.
I've also broken up the old "smoke" test (which was taking 2s on my
riscv64 qemu) to keep the total runtime for all the tests down to 200ms.
Test: treehugger
Change-Id: Icd939af51886fdf21432653a07373c1a0f26e422
Missed this when we added the new C23 binary output to the printf()
family.
Also fix %X to use "0X" instead of "0x" and add missing tests.
Test: used by new LD_SHOW_AUXV functionality
Change-Id: I6623b92acec7daf534536697de0f87352a2653ad
Talking futher to the person doing the glibc risc-v ifunc work, they
clarified that glibc _is_ passing hwcap as the first argument, and the
null pointer is actually the second argument.
https://sourceware.org/pipermail/libc-alpha/2023-August/150967.html
So since our whole purpose here was source compatibility, let's do what
they're actually doing, and let's add some tests. I've also added a test
that __riscv_hwprobe() works from an ifunc resolver because that's one
place where it might well be used. That said, one other thing that came
out of the discussion is that I actually went away and looked at a
sample of top apps to see how many are using ifuncs currently. The
result? Zero. So although this _might_ be interesting long term
(especially if clang gets riscv64 FMV), I think we've done more than we
need to with riscv64 ifuncs for now!
Test: ran locally, both dynamic and static tests
Change-Id: Ie2044d9f4e47c32c00ad381f045c537f4df38b08
This list has diverged between cts/ and bionic/. Instead of having to
maintain the list, let's just make cts/ inherit the one from bionic.
Bug: 296832150
Test: atest bionic-unit-tests CtsBionicTestCases
Change-Id: I271668e83aed239107b9129dfb707f03bae47cfa
Also fix a __has_include() that was copy & pasted without modification
from a different test.
Test: treehugger
Change-Id: Iafceb331a95ec788596ffdad60aa2202b692e589
Under some circumstances, it's possible to fail the enable allocation
limit android_mallopt call. Increase the total allowed time for the
function to complete.
In addition, if the enable fails, allow another limit call to succeed
in the future.
Finally, change the limit test to use _exit instead of exit.
Bug: 291672185
Test: Ran limit test thousands of times.
Test: Forced the limit to fail and verified the second call passes.
Change-Id: I0948e6fd97231a7538b9b82b76f0a207386681b1
We've had these backward all this time. The relevant quote is in a
code comment in the implementation, but the first call after
completely decoding a code point that requires a surrogate pair should
return the number of bytes decoded by the most recent call, and the
second call should return -3 (if only C had given those some named
constants that might have been more obviously wrong).
Bug: https://issuetracker.google.com/289419882
Test: Fixed the test, tests run against glibc and musl to confirm
Change-Id: Idabf01075b1cad35b604ede8d676d6f0b1dc91e6
Same as in uchar_test.cpp: glibc implements a much older unicode
standard which allows these.
Bug: None
Test: this is a test
Change-Id: Iead5eb01d391be85a7b1a034ea9e7f8828e81cdb
Same as the previous change for the uchar tests: the tests are wrong
to match bionic's wrong implementation. Fix the test to encode the bug
for now while I get the tests into good shape, then I'll be back to
fix the bugs and remove the test differences.
Bug: None
Test: this is a test
Change-Id: I1123660994f755f8bac1f2656f6890d5a43310b3
glibc immediately dereferences the locale passed to all wcsto*_l
functions, even if it won't be used, and even if it's
LC_GLOBAL_LOCALE, which isn't a pointer to valid memory.
Bug: None
Test: this is the test
Change-Id: Ia307cbd6a5c5b4b904c978a03e6d06c1cef6ceed
Change a test to use a signal that does not trigger a tombstone.
Also changed the gwp_asan_integration.DISABLED_assert_gwp_asan_enabled
test to inherit from the SilentDeathTest to prevent tombstones
being generated.
Test: Ran tests and no tombstones generated.
Change-Id: I0f104704829dde692aa515a63dea1c6971278c29
A few death tests are not set to silence tombstones, so fix
all of those occurrences.
Test: Ran all death tests and no tombstones generated.
Change-Id: If2b54b1a3432edbd54076439d40527d966607f70
The set_allocation_limit_multiple_threads test could fail every
once in a while. So rewrite slightly so that the tests wait until
all of the threads are running before letting them start.
I also refactored the code to use std::thread instead of the raw
pthread functions.
Bug: 291672185
Test: Ran the test thousdands of times.
Change-Id: Ia0bdef93d58e0ff8266e551ed4a32e14ff829581
These all appear to be either musl bugs or underspecified corners of
the C standard, so rather than verify the musl behavior I've just
disabled the body of the test for musl.
Now that this is skipped, all the uchar tests are passing for bionic,
glibc, and musl.
Bug: None
Test: None
Change-Id: Icf88ef42e9b750ab45ba76bf8112967b00e72a9f
Doesn't do anything for bionic (which is why this has gone unnoticed),
but it does change the locale for glibc and musl. After this patch,
all these tests pass on glibc. musl is still failing in
uchar.start_state, which I haven't finished investigating.
This should probably be a test fixture so it's harder to forget, but
there are a handful of tests here which don't call setlocale until
part way through the tests, and I'm not certain if that was attempting
to test some non-obvious behavior, or if that was just an accident. I
don't want to change that test behavior before understanding it
better, so this will do for now.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Ib781a41893f021e336e67281070932f41f792318
This one forgot to set its locale, so it was passing on glibc (because
the sequence here wasn't valid in its default locale) and failing on
musl, both for the wrong reasons.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Ic6bcd1836ba23c7010e2cde673a3beca73778021
Musl was treating 0xf0 as a valid character in its default locale. I
didn't dig into whether that was a musl bug or whether it was actually
translating whatever extended ASCII character that was into the
correct code point (tbh I don't know what the rule there is either).
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: I0845fdee9a016ad67ccff3716129ff29f83a63d7
Also actually assign a bool to it. I'd originally written a #define
and apparently forgot to fix the value. I'm a bit surprised that clang
didn't complain.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Iac46bc9c48fd70853d5c447e812e25e617281d2b
While looking at the disassembly for the epoll stuff I noticed that this
expands to quite a lot of code that the compiler can't optimize out for
LP64 (because it doesn't know that the "copy the argument into a local
and then use the local" bit isn't important).
There are two obvious options here. Something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
int signalfd(int fd, const sigset_t* mask, int flags) {
#if defined(__LP64__)
return signalfd64(fd, mask, flags);
#else
SigSetConverter set = {.sigset = *mask};
return signalfd64(fd, &set.sigset64, flags);
#endif
}
```
Or something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
#if defined(__LP64__)
__strong_alias(signalfd, signalfd64);
#else
int signalfd(int fd, const sigset_t* mask, int flags) {
SigSetConverter set = {};
set.sigset = *mask;
return signalfd64(fd, &set.sigset64, flags);
}
#endif
```
The former is slightly more verbose, but seems a bit more obvious, so I
initially went with that. (The former is more verbose in the generated
code too, given that the latter expands to _no_ code, just another symbol
pointing to the same code address.)
Having done that, I realized that slight changes to the interface would
let clang optimize away most/all of the overhead for LP64 with the only
preprocessor hackery being in SigSetConverter itself.
I also pulled out the legacy bsd `int` conversions since they're only
used in two (secret!) functions, so it's clearer to just have a separate
union for them. While doing so, I suppressed those functions for
riscv64, since there's no reason to keep carrying that mistake forward.
posix_spawn() is another simple case that doesn't actually benefit from
SigSetConverter, so I've given that its own anonymous union too.
Test: treehugger
Change-Id: Iaf67486da40d40fc53ec69717c3492ab7ab81ad6
Same as the earlier fix for mbrtoc16. Other implementations support
the older RFC, bionic supports the new one.
Bug: None
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Change-Id: I9e85a9ae53aaaa112a76665063acd2bd856b26cf
glibc and musl both interpreted the spec differently than we did
(better, imo) for the return value of a zero-length conversion. Fix
the test to handle that.
Also converted the test from ASSERT to EXPECT to reduce the number of
builds needed to find failures.
Bug: None
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Change-Id: Id74364040ce3b0e21bacd78f70467053cc8a6058
Also split that case out into a separate test to avoid complicating
the test for the common cases.
Bug: None
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.mbrtoc16"
Change-Id: If7e50f659ad99ee9bab8847fc7320c7bbd629c5d
The obsolete mips header rides again!
The most interesting part of this change is that I've removed the hack
that meant that all system call wrappers starting with `__` defaulted to
being hidden symbols. That's no longer useful given our linker scripts,
and it actively got in the way here because the public libc symbol
actually starts with `__` in glibc, and it would be weird and annoying
for developers if we chose a different name.
Test: strace
Change-Id: I230479787895e8e34f566ade36346a8241eea998
