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
This reverts commit 067bdc9546.
The angler/bullhead builds still use GCC, so I'll wait until they're turned down.
Bug: https://issuetracker.google.com/74404306
Change-Id: I777b08dd6ab5250d532b4b5cc56e9a790c13db20
NDK r18 (which removes GCC) is about to ship. We don't need this any more.
The immediate motivation for removing this right now is that the test
fails whenever we add Clang-only flags to the build system.
While we're here, clean up <stdatomic.h> too.
Bug: https://issuetracker.google.com/74404306
Test: ran tests
Change-Id: Iaad5d634d1ba76f0b6f19ad32cc27b2533771a4a
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
extern "C" and "C++" are parsed as a LinkageSpecDecl with the real Decl
as a child node. This leads to the preprocessor sticking its guard
between the extern specifier and the declaration.
Update the AST visitor to add a special-case for calculating the
SourceRange on a LinkageSpecDecl, and add a test.
Bug: https://github.com/android-ndk/ndk/issues/440
Test: python run_tests.py
Change-Id: I76445fe366cef46cfd2f16fb93d534d410c5edca
libc++ actually provides overloads for all the standard C library stuff,
so we just need to handle the POSIX and GNU extensions, of which there
are just two more: memrchr and strcasestr.
Bug: http://b/22768375
Test: builds
Change-Id: Ie9ed1fbcc794e14a0c9bba13b5307ad677949613
The versioner doesn't handle C++ blocks yet, so these guards won't be
added and it will appear as though the functions are always available
in C++, but based on API level in C.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/440
Change-Id: I31a20fa1596d836b280ffc6d7feb863afccca6c7
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
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
These still won't get guards added by the preprocessor, because it
compiles with C-only.
Bug: https://github.com/android-ndk/ndk/issues/440
Test: treehugger
Change-Id: I893b345e528ed1b761e0db00700037411bbb8b78
Apparently __strncpy_real redirects to strcpy instead of strncpy for GCC
builds. This is bad, and it confused a project compiled by GCC that uses
strcpy.
I audited all of the FORTIFY-related __RENAMEs both manually and with a
script I hacked together; they all look correct aside from this one.
FWIW, with the cleaned up clang FORTIFY, lots of the `void foo()
__RENAME(foo)` will just become `void foo()` if this last thing I'm
working on gets through review.
Bug: 35329524
Test: Previously broken project now seems to work. Bullhead and Ryu
both build + boot.
Change-Id: Ib18ee3535ae31eb7e8ae846dc012f9b64cac80bf
This gives more useful diagnostics if clang needs to mention these
functions (or a parameter of them).
Bug: 36984245
Test: m on bullhead completes successfully.
Change-Id: I17c2b624d08bc9dd3f08185b30029ed0c49ebb08
libcxx provides const-correct overloads for a few string.h functions.
These overloads use clang's enable_if attribute, so they're preferred
over our FORTIFY'ed equivalents.
This weakens _FORTIFY_SOURCE=2 when used with some of these functions,
since clang needs to see __pass_object_size in order to pass an accurate
result for __builtin_object_size(s, 1) at a callsite. Since those
functions don't have __pass_object_size on their params, clang can't do
that. This makes LLVM lower the __builtin_object_size calls, which means
we get the same result as __builtin_object_size(s, 0).
We have to provide all of the overloads in Bionic, since enable_if is
only used to disambiguate overloads with (otherwise) the same type. In
other words:
// overload 1
char *strchr(const char *, int s) __attribute__((enable_if(1, "")));
// overload 2
char *strchr(char *, int s);
void foo() {
char cs[1] = {};
strchr(static_cast<const char *>(cs), '\0'); // calls overload #1.
strchr(cs, '\0'); // calls overload #2.
}
Bug: 34747525
Test: m checkbuild on bullhead internal master + AOSP. vts -m
BionicUnitTests passes on both. Surprisingly, the only code that this
seems to break is contained in Bionic.
Change-Id: Ie406f42fb3d1c5bf940dc857889876fc39b57c90
I dunno why I used __bos0 in the first place; clang's strrchr (and
GCC's strchr+strrchr) both use __bos.
Bug: 34747525
Test: m. Device still boots. cts -m BionicUnitTests shows no new
failures.
Change-Id: Ifec0e05a6a1144fa3e3ac70562af3ec57c09c194
The deprecated headers have always had only the POSIX definition
available (and it's always been available). With the unified headers
as they are now, we actually make it unavailable for C++ users (C++
implies _GNU_SOURCE) targeting below M. Adding this guard means that
pre-M users will still at least get the POSIX one.
It's not great that moving to M as your target API will actually
change the signature of your strerror_r, but I don't see a better
option here (not until we have the compatibility library, anyway).
Test: make checkbuild
Bug: None
Change-Id: I2d15702467533a826c4ec10fd973ee929d2b562a
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
We can't really add these to the unified headers yet since we're
still using the old headers as well, and libandroid_support needs to
work with both. These functions are already defined in
libandroid_support, so when using unified headers we'll get duplicate
definitions.
This was only going to be a temporary solution anyway. Instead we'll
just rely on libandroid_support (and eventually its rewrite) to handle
these.
This reverts commit 6576a3749b.
Test: ./tools/update_headers.py && make ndk && make native
# Copied into working directory for unified headers NDK work.
ndk/checkbuild.py
ndk/run_tests.py --force-unified-headers
Bug: None
Change-Id: I5762e815e2030c89d7f2540df08dd67b6c2d10a5
These names were pretty misleading (aka "backwards"), so switch to the
same obvious names glibc uses.
Test: build.
Change-Id: Ia98c9dbbccd0820386116562347654e84669034a
Various things:
* work around -Wnullability-completeness.
* use C++ casts in C++ and C casts in C.
* stop using attributes clang doesn't support (such as `warning`).
* remove duplicate definitions of XATTR_CREATE and XATTR_REPLACE.
Change-Id: I07649e46275b28a23ca477deea119fe843999533
http://clang.llvm.org/docs/AttributeReference.html#nonnull
_Nonnull is similar to the nonnull attribute in that it will instruct
compilers to warn the user if it can prove that a null argument is
being passed. Unlike the nonnull attribute, this annotation indicated
that a value *should not* be null, not that it *cannot* be null, or
even that the behavior is undefined. The important distinction is that
the optimizer will perform surprising optimizations like the
following:
void foo(void*) __attribute__(nonnull, 1);
int bar(int* p) {
foo(p);
// The following null check will be elided because nonnull
// attribute means that, since we call foo with p, p can be
// assumed to not be null. Thus this will crash if we are called
// with a null pointer.
if (src != NULL) {
return *p;
}
return 0;
}
int main() {
return bar(NULL);
}
Note that by doing this we are no longer attaching any sort of
attribute for GCC (GCC doesn't support attaching nonnull directly to a
parameter, only to the function and naming the arguments
positionally). This means we won't be getting a warning for this case
from GCC any more. People that listen to warnings tend to use clang
anyway, and we're quickly moving toward that as the default, so this
seems to be an acceptable tradeoff.
Change-Id: Ie05fe7cec2f19a082c1defb303f82bcf9241b88d
Including glibc's <libgen.h> will result in the user getting the POSIX
version of basename always, regardless of when it is included relative
to <string.h>. Prior to this patch, our implementation would result in
the one that's included first winning.
Bug: http://b/25459151
Change-Id: Id4aaf1670dad317d6bbc05763a84ee87596e8e59
Interestingly, this mostly involves cleaning up our implementation of
various <string.h> functions.
Change-Id: Ifaef49b5cb997134f7bc0cc31bdac844bdb9e089
Strictly speaking, this only implements the _l variants of the functions
we actually have. We're still missing nl_langinfo_l, for example, but we
don't have nl_langinfo either.
Change-Id: Ie711c7b04e7b9100932a13f5a5d5b28847eb4c12
__open_2() is used by the fortify implementation of open(2) in
fcntl.h, and as such needs an unmangled C name. For some reason
(inlining?), this doesn't cause problems at the default optimization
level, but does for -O0.
The rest of these didn't cause build failures, but they look suspect
and probably will, we just haven't caught them yet.
Bug: 17784968
Change-Id: I7391a7a8999ee204eaf6abd14a3d5373ea419d5b
We already had the POSIX strerror_r, but some third-party code defines
_GNU_SOURCE and expects to get the GNU strerror_r instead.
This exposed a bug in the libc internal logging functions where unlike
their standard brethren they wouldn't return the number of bytes they'd
have liked to have written.
Bug: 16243479
Change-Id: I1745752ccbdc569646d34f5071f6df2be066d5f4
Fix and use __RENAME (and lose ___RENAME --- two underscores should be
enough for anybody). This was the point of this change, because I want
to use __RENAME to support the two basename variants and the two
strerror_r variants.
Lose a bunch of macros that weren't being used.
Lose three dead files from the DNS code.
Change-Id: I3ef645c566b16a52217bc2e68c7d54b37c7c9522
