Bazel doesn't like it when modules produce files with the same name
as the module itself, and gives warnings.
Rename either the module or file in this case so that the file has
an extension and the module doesn't.
Bug: 198619163
Test: m nothing
Change-Id: Ic4592b06f575496ffd54ac75cb4d682118b29d93
If we switch from x18 to gp for shadow call stack, we're going to need
another slot in jmp_buf. We'll need this even for hardware shadow call
stacks too.
While I'm here, and because this is likely my last chance, let's just
round this up to 32 for safety. musl and glibc only have the minimum
needed (which I think means they'll need an ABI break to support SCS
unless they just use a callee-saved general purpose register), but since
we can't do ABI breaks after we ship, let's play it safe.
Bug: https://github.com/google/android-riscv64/issues/72
Test: treehugger
Change-Id: I60661fb7a308c900bfd08c9361f51919b798c005
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
Now <utmpx.h> isn't any more useful on Android than <utmp.h> is, but it
is POSIX, and -- importantly -- we can implement it with just a header
file, so code can use it on every existing API level.
macOS does indeed only have the <utmpx.h> functions (although it does
still have the <utmp.h> header!), so potentially portable code might
want <utmpx.h> on Android. (glibc/musl both have both headers.)
Bug: https://github.com/landley/toybox/pull/213
Test: treehugger
Change-Id: Iaa88167708182009a63e2e1a15f11186b251ed02
All the other architectures are already polluting the namespace with
`struct ucontext`, so make riscv64 match for source compatibility with
other Android code. (Code _should_ be using the POSIX `ucontext_t`, but
ART in particular had a lot of `struct ucontext`, and although I'll
clean that up separately, if there's some in our tree, there's probably
a lot more out there in the wild.)
Test: treehugger
Change-Id: Id0e4e97e660d7d60e792cd2462ddb9788d4772d7
We're going to dereference a null pointer if you pass one instead of a
pointer to a path, but at the moment (because of implementation sharing
between the different file actions) we won't do it until the last
minute, in the child itself. Let's crash as soon as you make the mistake
instead, to make debugging a lot easier.
Test: treehugger
Change-Id: I987d2700ba05b9867a936ebe770224259376633f
We don't really need <linux/compiler.h> and <linux/compiler_types.h>. We
already have a mechanism to remove unused macros, so let's do that. We
don't currently have a way to remove unused #includes, so we still need
<linux/compiler.h> and <linux/compiler_types.h> files (but I've clarified
the comments in them).
I've kept the empty definitions of `__user` and `__force` for source
compatibility. (We had one security test at least that was assuming
a kernel struct definition will "just work".)
Bug: http://b/262917450
Test: treehugger
Change-Id: Iacbbbc1aeef9a4fac52dabd7811ab875cc267d4f
Move the "is there a comparator?" check into the sole caller, to match
the "is there a filter?" check. Remove the unnecessary (and unlikely)
pre-sort "is the array empty?" check.
Test: treehugger
Change-Id: I8bd461380420dce4a8bc05ef5fe3511b26347d7c
While these tests were running, other native processes would get torture GWP-ASan. This can lead to OOMs.
Bug: 273904016
Change-Id: Ia813a73bfc1c379633be022dbf4b7d567069c731
Test: atest bionic-unit-tests (in presubmit)
No idea if this will be the actual API level or not, but that's all
the more reason to abstract it away early...
Bug: None
Test: None
Change-Id: I8a17bb42dbb08a6e760427514af8331e7dc9b549
