This doesn't address `struct sigaction` and `sigaction`. That will
come later.
Bug: http://b/72493232
Test: ran tests
Change-Id: I4134346757ce3a4dac6feae413361cec16223386
The history has no motivation for <asm/termbits.h>, and other C libraries
don't seem to include any of the extra types and constants that gains us.
This caused problems building FFMPEG, which defines its own B0.
Bug: https://github.com/android-ndk/ndk/issues/630
Test: builds
Change-Id: If032b9fa7860777c13f7bd8e68fb78ff606dcd94
* Variadic functions usually cannot be inlined.
* Do not use misleading __always_inline attribute,
and also avoid early clang 7.0 compiler bug.
Bug: 72412382
Test: build and boot aosp*-eng in emulator
Change-Id: I7490976166581abc626f397ad408581ada0ed308
This adds a new mechanism to say "replace struct S with #include <bits/S.h>".
Also switch epoll_event over to the new mechanism.
Also use the kernel's struct sockaddr_storage directly rather than behind
an unnecessary #define.
This patch also removes some dead code in the header scrubber. This code
still needs rewriting completely. I learned that a "block" isn't necessarily
a single struct definition, say; it might be a run of them. It seems like
a block is a run of preprocessor directives or a run of regular code.
Bug: https://issuetracker.google.com/36987220
Test: new test
Change-Id: Ic6a5c09559766a4babe3cd4c3ea538b885e07308
And fix one thing that this found: apparently <stdlib.h> should also
make the various *WAIT* macros available.
Bug: N/A
Test: builds
Change-Id: Id879bf3c1bddd1170261a809e7280150a74d6b3d
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
Having FORTIFY enabled for clang-tidy adds no value, and breaks some
heuristics for recognizing standard library functions (see the bug).
This also disables FORTIFY for the static analyzer (which we use
through clang-tidy), because it presumably tries to recognize standard
library functions through similar heuristics.
Bug: 36664104
Test: mma with and without the patch to cdefs. New test breaks without.
Change-Id: I40c66ff9e638b306878ada006bc2c98f2346e77a
Autosubmit fired before the CL was actually ready (forgot to hit "y"
on the repo upload).
Test: make checkbuild
Test: copied into the NDK and ran mmap64_fob64 test.
Bug: lots
Change-Id: I8c0400a703f319e8e230f7ba9178009ed7c88be0
While this was never an inline, this function alone has caused most of
the bug reports related to _FILE_OFFSET_BITS=64. Providing an inline
for it should allow a lot more code to build with _FILE_OFFSET_BITS=64
when targeting pre-L.
Test: make checkbuild
Test: built trivial cc_binary for LP32 against API 14 with
_FILE_OFFSET_BITS=64 set
Bug: lots
Change-Id: I8479d34af4da358c11423bee43d45b59e9d4143e
iOS 10 has <sys/random.h> with getentropy, glibc >= 2.25 has
<sys/random.h> with getentropy and getrandom. (glibc also pollutes
<unistd.h>, but that seems like a bad idea.)
Also, all supported devices now have kernels with the getrandom system
call.
We've had these available internally for a while, but it seems like the
time is ripe to expose them.
Bug: http://b/67014255
Test: ran tests
Change-Id: I76dde1e3a2d0bc82777eea437ac193f96964f138
We can cut a lot of stuff out of the NDK's libandroid_support with this,
and reduce unnecessary relocations for all LP32 code. LP64 code should
be unaffected.
Bug: https://issuetracker.google.com/64450768
Bug: https://github.com/android-ndk/ndk/issues/507
Test: ran tests, plus manual readelf on the _test.o files
Change-Id: I3de6015921195304ea9c829ef31665cd34664066
strace 4.19 causes clang to emit a questionable warning:
external/strace/nlattr.c:254:35: error: format specifies type 'unsigned long' but the argument has type 'unsigned long long' [-Werror,-Wformat]
tprintf("htobe64(%" PRIu64 ")", be64toh(num));
~~~ ^~~~~~~~~~~~
bionic/libc/include/sys/endian.h💯20: note: expanded from macro 'be64toh'
#define be64toh(x) htobe64(x)
^~~~~~~~~~
bionic/libc/include/sys/endian.h:80:17: note: expanded from macro 'htobe64'
#define htobe64 __swap64
^
bionic/libc/include/sys/endian.h:48:18: note: expanded from macro '__swap64'
#define __swap64 __builtin_bswap64
^
What's happened here is:
* be64toh is __builtin_bswap64
* PRIu64 is "lu"
* __builtin_bswap64 is internally declared a "ULLiULLi"
All of which leads to the `unsigned long` != `unsigned long long` complaint.
It seems like __builtin_bswap64 should be ULiULi on 64-bit architectures,
where `long` rather than `long long` is the natural way to refer to 64-bit
types, as evidenced by the "lu" for PRIu64.
As long as clang behaves like this, though, we can work around it with a cast.
Also clean up the other casts in the file, be more consistent about whether
these function-like macros are defined with an argument, and remove an
incorrect comment.
Bug: http://b/65495954
Test: ran tests, built strace 4.19 without warnings
Change-Id: I8e06d4bf71e95d62f556eab8661033e04d487e0d
FORTIFY's *_chk functions mess with ASAN's library function
interceptors, which can apparently result in false-positives.
Since adding even more complexity to every run-time check condition in
FORTIFY doesn't seem like a great idea, and the majority of our builds
will still use FORTIFY anyway, turning FORTIFY off here seems
reasonable.
Bug: 63104159
Test: checkbuild on internal master + CtsBionicTestCases. No new
failures.
Change-Id: Id32e551e28ee70a9815ad140c3253b86f03de63f
This reverts commit 9af9120091 (a revert
of 079bff4fa5), now the versioner bug is
fixed.
Bug: http://b/64613623 # header bug
Bug: http://b/64802958 # versioner bug
Change-Id: I1cb9d7832d4b3aecdc57a9285e2291443e59d02d
This reverts commit 079bff4fa5.
Broke builds with SANITIZE_HOST=address with an asan failure in versioner.
Change-Id: I22b113fd5405589d1a25e5e137c450aaba1ade5f
GCC's FORTIFY required optimizations to be enabled in order to function
properly. Clang's FORTIFY doesn't have this limitation, so it seems
pointless to keep it disabled due to a GCC-specific limitation.
Bug: 12231437
Test: Checkbuild on bullhead internal master + CtsBionicTestCases. No
new failures.
Change-Id: I74aa35f9d3f3d2a6b11a7adfe72a787e3d7f7f36
We've never really used __restrict: only <string.h> and <stdio.h> (which
are still very similar to upstream BSD headers) consistently have these
annotations. Neither clang nor GCC warns for trivial cases, and there's
little obvious documentation benefit.
Bug: http://b/30833514
Test: builds
Change-Id: I3e4384281865475d0c55d764b546d8166419ee31
I plan on having one review per file for the enable_if->diagnose_if
FORTIFY migration. Having this in means that no one review is dependent
on another.
Bug: 12231437
Test: m.
Change-Id: Ic0b07d7f7f6782e371c8792eb1e40cdfa32d3e35
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
It's not usable for cases where the off_t and off64_t functions became
available in different API levels, so it's not as big an improvement as
we'd hoped, but it cleans up several headers and should be usable for
any future additions (though recent Linux additions have _only_ supported
off64_t anyway).
Bug: N/A
Test: builds
Change-Id: I18b00f30666079d9d12d5b9c0ed916076d6c3641
Convenience macro for __RENAME if __USE_FILE_OFFSET64 mode. Lets us
avoid duplicating all the doxygen comments in frameworks headers.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/459
Change-Id: Ica44f22b2f1596e484694006c0926d94d16187b5
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
x86 needs the <sys/user.h> additions, x86-64 the <sys/procfs.h> ones.
Bug: N/A
Test: ndkports x86 and x86_64 binutils-2.28
Change-Id: I2e4738d3f8343d12db0536ca77045e2a0ccc6596
* TTYDEF_OFLAG referred to the BSD OXTABS constant instead of the Linux XTABS,
so references to it wouldn't compile.
* CEOL was incorrect (compared to `stty -a`).
* ttydefchars wouldn't compile (removed rather than attempt to fix something
of unclear utility).
Bug: http://b/63145226
Test: new test
Change-Id: I823e5eaab789cafd2eeea03f77ea553346822f74
Building ruby actually trips over both of these:
* if the RTLD_ constants aren't #defined, it uses its own incorrect values.
* if the REG_ constants aren't #defined, it confuses x86 with x86-64.
In all other places where we have enums in our headers, we already match
existing glibc practice.
Bug: http://b/62531921
Test: builds
Change-Id: I5b3aab25a1a24611bdc58f2eda4104a78e9f841c
In a similar style to some of our other "not really, but enough" headers
like <sys/vt.h>.
Bug: N/A
Test: build GNU dd or BSD dd with a standalone toolchain
Change-Id: I8fbd1aac1d97e24b05e7aae8a55666300b5bf1ed
boost (1.64.0 at least) assumes that if you have POSIX_MADV_NORMAL, you have
posix_madvise. With unified headers, this isn't true. Rather than make life
harder for projects that don't use configure, just make it so. We already
applied similar workarounds for epoll_create1 and inotify_init1.
Bug: https://github.com/android-ndk/ndk/issues/395
Test: built boost (long story!)
Change-Id: I5d2d8de7b30921dde913251d35dcd249a2876f94
<sys/types.h> unconditionally includes <sys/sysmacros.h>.
<sys/sysmacros.h> defines major, minor, and makedev. In the deprecated NDK
headers, these were inline functions. In the unified headers, they are
function-like macros.
The inline functions would only collide with another function called major,
minor, or makedev but the macros will replace anything with a function-like
form such as definitions of class methods called major, minor, or makedev.
This causes code which has such definitions to fail to compile when moving
from the deprecated headers to the unified headers.
Resolve this by removing the transitive dependency. Folks who want
<sys/sysmacros.h> can ask for it explicitly (it's been in both bionic and
glibc for years, though I don't think macOS has it [as usual]).
Bug: https://github.com/android-ndk/ndk/issues/398
Test: builds
Change-Id: If2921c7b5d979c3066f199f22c64d4d2f7bf6632
Some third-party code uses the existence of IN_CLOEXEC/IN_NONBLOCK to
detect the availability of inotify_init1. This is not correct, since
`syscall(__NR_inotify_init1, IN_CLOEXEC)` is still valid even if the C
library doesn't have that function, but for the time being we don't
want to harm adoption to the unified headers. We'll avoid defining
IN_CLOEXEC and IN_NONBLOCK if we don't have inotify_init1 for the time
being, and maybe revisit this later.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/394
Change-Id: Iefdc1662b21045de886c7ad1cbeba6241163d943
Some third-party code uses the existence of EPOLL_CLOEXEC to detect
the availability of epoll_create1. This is not correct, since having
up-to-date UAPI headers says nothing about the C library, but for the
time being we don't want to harm adoption to the unified headers.
We'll undef EPOLL_CLOEXEC if we don't have epoll_create1 for the time
being, and maybe revisit this later.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/302
Bug: https://github.com/android-ndk/ndk/issues/394
Change-Id: I8ee9ce62768fb174070ec51d114f477389befc4a
This is a bit bogus because it's been removed from glibc (though not
thoroughly) and is never useful on Android (because the system calls
in question are compiled out of Android kernels, and SELinux would
disallow them even if you weren't running an Android kernel). This
also means that on glibc you need to include <linux/sem.h> for this
and on bionic you need <sys/sem.h> (and for either if you #include
the other file, you won't get this union).
Bug: https://github.com/android-ndk/ndk/issues/400
Test: added new test
Change-Id: I47f721da77515531f616d6ad8479bfbc9b60ee47
AP_FPUCW is referenced by valgrind.
Bug: https://bugs.kde.org/show_bug.cgi?id=339945
Test: valgrind builds with one less hack
Change-Id: I7146f3709286662108cc82ba3c55ce935375a1f1
