If folks want to use this instead of PAGE_SIZE, let's let the compiler
know that it doesn't need to be called more than once. Using "const"
rather than "pure" lets us cover more cases, and although this function
may need to check global state, it's _immutable_ global state, so it's
effectively "const".
Test: llvm-objdump -d
Change-Id: I0b13de79d44b57545258121df7cdd6490a9a5be1
The NDK no longer supports API levels earlier than 21.
This *doesn't* include <ctype.h> because I have a separate change
rewriting that (that's blocked on the upcoming libc++ update).
Test: treehugger
Change-Id: I53e915f27011dfc0513e0c78d8799377e183ceca
The next NDK to take these headers only supports API 21 and later, so
clean up some of the trivial cruft.
This doesn't include the remaining "legacy inlines", since they're a bit
more complicated. I'll remove those in later changes.
Test: treehugger
Change-Id: I94c32f6393dd3ae831165917303ea591222baa0d
See:
https://man7.org/linux/man-pages/man2/close_range.2.html
Note: 'man close_range' documents 'flags' as unsigned int,
while glibc unistd.h as just 'int'. Picking 'int' to match glibc,
though it probably doesn't matter.
BYPASS_INCLUSIVE_LANGUAGE_REASON=man is a cli command
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e2d1c8edc2ea28922d60f3ce3e534a784622cd1
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
The NDK doesn't support anything older than API level 16, so remove some
more clutter.
Test: builds
Change-Id: If257a27841396af001b089b7ae0fbd8c3e0128e4
The NDK only supports >= 16, so remove anything older than that to avoid
giving the misleading impression that such old targets are still
supported.
(This change doesn't touch <unistd.h>. I'll follow up with that once the
outstanding FORTIFY changes to that file are in.)
Test: builds
Change-Id: I6cc6ecdb99fe228a4afa71f78e5fd45309ba9786
When building the bionic tests, we use -fno-builtins, which turns off
clang's recognition of vfork as a magical function that can return
twice. Explicitly annotate our returns_twice functions to ensure that
we generate correct code even in -fno-builtins (and while we're at it,
annotate the no_return functions as well, so we generate faster code).
Bug: http://b/131856005
Test: treehugger
Change-Id: I465f8042a965f0c7c03caa5f17af67deea8f5d9d
In particular, document the fact that they only affect the calling thread
on Android.
Bug: http://b/13134174
Test: ran tests
Change-Id: Ica6af451400d47e24358f59495ded63b2110eb8b
Now that we have a clang that supports transparent overloads, we can
kill all of this cruft, and restore our upstream sources to their
untouched glory. Woohoo!
Bug: 12231437
Test: Built aosp_marlin; no obvious patch-related aosp_mips issues.
Change-Id: I520a19d014f12137f80e43f973dccd6711c571cd
We're still seeing lots of confusion. People do seem to look as far as
the headers, but stop there. So let's try a bit harder to point them in
the right direction.
Also explicitly state that removing _FILE_OFFSET_BITS=64 is the
behavior-preserving fix for compilation problems when upgrading to NDK
r15 or later.
Bug: N/A
Test: N/A
Change-Id: I2d5c65b2fb5cccb9977901e51fea1ad2ccc0fd95
I'm skeptical about the usefulness of this, but it's in POSIX, it's
in glibc (but not iOS), and it is used in some internal source (test
runners and container code).
Bug: N/A
Test: ran tests
Change-Id: I92c5398f2a679b21a33fba92bc8e67e3ae2eb76f
Surprisingly to me, there are actual uses of `swab` in the codebases
I have available to search, including one with a #ifndef __ANDROID__
around it.
Bug: N/A
Test: ran tests
Change-Id: Ic91b78ae22bb65c346cb46dd38916f48d979abe0
Spotted while adding syncfs(2). I'd previously seen that this file already
had names, but apparently not inspected them. A couple were missing, a
couple (pipe/pipe2) could usefully have a more specific type, and many
hadruntogethercstylenames.
Bug: http://b/64613623
Test: builds
Change-Id: I6b4a131bf51bf04825317ec481bc55e87c88c2b3
GMM calls this system call directly at the moment. That's silly.
Bug: http://b/36405699
Test: ran tests
Change-Id: I1e14c0e5ce0bc2aa888d884845ac30dc20f13cd5
This patch cleans up our standard headers by moving most of the FORTIFY
cruft out in to its own sandbox. In order to include the *_chk and
*_real declarations, you can either enable FORTIFY, or `#define
__BIONIC_DECLARE_FORTIFY_HELPERS`.
Both sys/select.h and strings.h are explicitly ignored by this patch.
Both of these files have very small __BIONIC_FORTIFY blocks, and don't
define any actual FORTIFY'ed functions (just macros, and 3 *_chk
functions).
This patch also makes the versioner ignore the FORTIFY implementation
headers, since we're guaranteed to pick the FORTIFY'ed headers up when
looking at the regular headers. (...Not to mention that making the
FORTIFY'ed headers freestanding would be annoying to do and maintain for
~no benefit).
We bake the knowledge of where FORTIFY headers live directly into the
versioner. We could go with a more general approach (e.g. adding an -X
IGNORED_FILE flag that tells the versioner to ignore
$HEADER_PATH/$IGNORED_FILE), but we'd then have to repeat that for every
test, every manual invocation of the versioner, etc. for no benefit
that's obvious to me.
Bug: 12231437
Test: m checkbuild on bullhead internal master + CtsBionicTestCases. no
new errors.
Change-Id: Iffc0cc609009b33d989cdaddde0a809282131a5b
We had several bugs filed saying "if I set _FILE_OFFSET_BITS=64 when
targeting an API < L, various functions are missing". Instead of
saying "yes, they are", we quietly just modified the header files to
expose the non-64-bit variants. This makes no sense. We can't just say
"oh, yeah, we don't have a version of this function that agrees with
your calling code about how large off_t is, but here's a version that
doesn't: I'm sure it'll be fine".
_FILE_OFFSET_BITS=64 on Android LP32 has always been a game of chance,
but that game should be "are all the functions my code needs available
at compile time?", not "will my code actually work at run time?".
Bug: https://github.com/android-ndk/ndk/issues/449
Bug: https://github.com/android-ndk/ndk/issues/442
Bug: https://github.com/android-ndk/ndk/issues/333
Bug: https://github.com/android-ndk/ndk/issues/332
Bug: https://github.com/android-ndk/ndk/issues/324
Test: builds
Change-Id: Ib095251d3e21e77ed50cc3575388107fecec4ecd
pass_object_size(N) forwards the result of __builtin_object_size(param,
N) to a function. So, a function that looks like:
size_t foo(void *const p __pass_object_size) { return __bos0(p); }
int bar = foo(baz);
would effectively be turned into
size_t foo(void *const p, size_t sz) { return sz; }
int bar = foo(baz, __bos(baz)); // note that this is not __bos0
This is bad, since if we're using __bos0, we want more relaxed
objectsize checks.
__bos0 should be more permissive than __bos in all cases, so this
change Should Be Fine™.
This change also makes GCC and clang share another function's
implementation (recv). I just realized we need to add special
diagnostic-related overloads bits for clang to it, but I can do that in
another patch.
Bug: None
Test: Bullhead builds and boots; CtsBionicTestCases passes.
Change-Id: I6818d0041328ab5fd0946a1e57321a977c1e1250
This patch adds clang-style FORTIFY to Bionic. For more information on
FORTIFY, please see https://goo.gl/8HS2dW . This implementation works
for versions of clang that don't support diagnose_if, so please see the
"without diagnose_if" sections. We plan to swap to a diagnose_if-based
FORTIFY later this year (since it doesn't really add any features; it
just simplifies the implementation a lot, and it gives us much prettier
diagnostics)
Bug: 32073964
Test: Builds on angler, bullhead, marlin, sailfish. Bionic CTS tests
pass on Angler and Bullhead.
Change-Id: I607aecbeee81529709b1eee7bef5b0836151eb2b
These names were pretty misleading (aka "backwards"), so switch to the
same obvious names glibc uses.
Test: build.
Change-Id: Ia98c9dbbccd0820386116562347654e84669034a
Give a compile time diagnostic when the nullptr sentinel is missing
from an execl family call, instead of just pulling arbitrary values.
Bug: http://b/30793878
Change-Id: I1c49005c58b7ad4a5b04f0435b722d4c744e8f0e
Test: Built bullhead
Future API levels aren't known (e.g. 25 could be a maintenance release
of N that doesn't contain any bionic updates), so use a placeholder
macro that we can find and replace with the actual API level before each
release.
Bug: http://b/28178111
Change-Id: I667fe53ea1ac49b64135170fc30d5dbe9df94e29
