This showed up as open_memstream not being visible in <stdio.h>
if only _GNU_SOURCE was defined.
Bug: 17361504
Change-Id: I38f9843f4e6ee770a6325ad50f779bda5495ffca
This is needed to make L work correctly, and bionic tests pass
again, after applying the equivalent of
commit 00aaea364501b3b0abe58dae461136159df1e356 there.
It makes the preexisting code that uses __sync implementations
much more useful, although we should no longer be exercising that
code in AOSP.
Specifically fixes:
We were invoking __has_extension and __has_builtin for GCC compilations.
They're clang specific. Restructured the tests.
The __sync implementation was not defining the LOCK_FREE macros.
ATOMIC_VAR_INIT was using named field initializations. These are a
C, not C++, feature, that is not supported by g++ 4.6.
The stdatomic bionic test still failed with 4.6 and glibc with our
questionable LOCK_FREE macro implementation. Don't run that piece
with 4.6.
In L, this is a prerequisite for fixing:
Bug:16880454
Bug:16513433
Change-Id: I9b61e42307f96a114dce7552b6ead4ad1c544eab
(cherry picked from commit 32429606bf696d3b2ca555f132a0d60c566d0bd0)
Stdatomic.h was potentially redefining _Atomic, in spite of a
prior definition by <atomic>. This could cause g++ builds that
included <stdatomic.h> with an available <atomic> header to break.
A functional stdatomic.h is a prerequisite for fixing the
following bugs. This is the middle of 3 AOSP updates to
bionics stdatomic.h that are needded to get there.
Bug:16880454
Bug:16513433
Change-Id: I562c7115118c0587d594d4d5b62d25101e47bfd8
(cherry picked from commit 3e4a0099a179d7acee63d78c8fc4c3cc7b0bae42)
We seem to use this stdatomic.h sometimes, and slightly different prebuilts
at other times, making them all difficult to test, and making it unclear
which one we're testing. This generalizes the bionic header so that it
can be used directly as the prebuilt header as well. So long as they
don't diverge again, that should somewhat improve test coverage.
Use the correct builtin for atomic_is_lock_free.
Fix atomic_flag_init.
Turn on atomic tests even with __GLIBC__, since they now appear to pass.
Include uchar.h in stdatomic.h where needed.
Add a basic memory ordering test.
Fix bit-rotted comments in bionic tests makefile.
Prerequisite for fixing b/16880454 and
Bug:16513433
Change-Id: If6a14c1075b379395ba5d93357d56025c0ffab68
(cherry picked from commit 00aaea364501b3b0abe58dae461136159df1e356)
This is needed to make L work correctly, and bionic tests pass
again, after applying the equivalent of
commit 00aaea364501b3b0abe58dae461136159df1e356 there.
It makes the preexisting code that uses __sync implementations
much more useful, although we should no longer be exercising that
code in AOSP.
Specifically fixes:
We were invoking __has_extension and __has_builtin for GCC compilations.
They're clang specific. Restructured the tests.
The __sync implementation was not defining the LOCK_FREE macros.
ATOMIC_VAR_INIT was using named field initializations. These are a
C, not C++, feature, that is not supported by g++ 4.6.
The stdatomic bionic test still failed with 4.6 and glibc with our
questionable LOCK_FREE macro implementation. Don't run that piece
with 4.6.
In L, this is a prerequisite for fixing:
Bug:16880454
Bug:16513433
Change-Id: I9b61e42307f96a114dce7552b6ead4ad1c544eab
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
GCC assembler allows xyz to be redeclared as weak,
by __weak_alias(xyz, _xyz), while _xyz is undefined.
Clang does not like that but silently generates no code.
It will reject its own .s file if the assembly code is saved first.
Since we have no reason to define xyz or _xyz as weak symbol now,
and _xyz is a macro to xyz, we simplify libC to have only
xyz defined as global.
BUG: 17186746
Change-Id: I24b154425838683cae69248cc750c59e26fd5467
Stdatomic.h was potentially redefining _Atomic, in spite of a
prior definition by <atomic>. This could cause g++ builds that
included <stdatomic.h> with an available <atomic> header to break.
Change-Id: I562c7115118c0587d594d4d5b62d25101e47bfd8
We seem to use this stdatomic.h sometimes, and slightly different prebuilts
at other times, making them all difficult to test, and making it unclear
which one we're testing. This generalizes the bionic header so that it
can be used directly as the prebuilt header as well. So long as they
don't diverge again, that should somewhat improve test coverage.
Use the correct builtin for atomic_is_lock_free.
Fix atomic_flag_init.
Turn on atomic tests even with __GLIBC__, since they now appear to pass.
Include uchar.h in stdatomic.h where needed.
Add a basic memory ordering test.
Fix bit-rotted comments in bionic tests makefile.
Change-Id: If6a14c1075b379395ba5d93357d56025c0ffab68
Also remove declaration.
The only user is compiler-rt, and they can replace that call with one to
syscall(2). compiler-rt doesn't currently build on mips64 anyway.
Bug: 11156955
Change-Id: Ieae0ba49c8e7aa50253401fc1d7c2d17bc867d39
Removes the leading underscores from __android_set_abort_message() and
moves its declaration into a public header file.
Bug: 17059126
Change-Id: I470c79db47ec783ea7a54b800f8b78ecbe7479ab
(cherry picked from commit ce6b1abbb1da797e716d8ec03da4e3b6304fd11d)
(cherry picked from commit 3a25ab952befbe908f6df45805683ebe3bf65863)
No one's reported this, but I saw it in an Android port of fuser(1).
We still have lots of problems in our network headers because we
get most of the structs direct from the kernel, and it doesn't use
types like this (which is why we've got away without this one for
so long). One day we should probably look at cleaning that up, but
doing so can wait.
Change-Id: If15edf0cfc32716fa312d7ed97c48321b760d979
This way it's a lot harder for us to screw up (since we should always
be including <sys/cdefs.h> anyway).
Bug: 14659579
Change-Id: I23070fff3296b0d1c683bb5e3a6e214146327d53
Needed for __BEGIN_DECLS/__END_DECLS. Currently fine because it's being
included after other files that do this.
Change-Id: I1f12368fc461f6ef5ca90992cf19f317f0b5d7af
Removes the leading underscores from __android_set_abort_message() and
moves its declaration into a public header file.
Bug: 17059126
Change-Id: I470c79db47ec783ea7a54b800f8b78ecbe7479ab
<features.h> is supposed to take user-settable stuff like _GNU_SOURCE
and _BSD_SOURCE and turn them into __USE_GNU and __USE_BSD for use in
the C library headers. Instead, bionic used to unconditionally define
_BSD_SOURCE and _GNU_SOURCE, and then test _GNU_SOURCE in the header
files (which makes no sense whatsoever).
Bug: 14659579
Change-Id: Ice4cf21a364ea2e559071dc8329e995277d5b987
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
This is an alternate, somewhat simpler, fix that makes it safe to
include both <atomic> and <stdatomic.h> from C++ code in either order.
It means that C code consistently uses one implementation of atomics
and C++ another. We still have to make sure that those two
implementations interoperate correctly at runtime; in particular,
any flavor of atomic object needs to be represented exactly like the
underlying type, with the proper alignment constraint.
Bug:17007799
Change-Id: Iffcfc5220d8fa150f89dd083a121b24d23f268fc
(cherry picked from commit 019d3958118b7dc3ec8444ad2accca50c268b737)
This is an alternate, somewhat simpler, fix that makes it safe to
include both <atomic> and <stdatomic.h> from C++ code in either order.
It means that C code consistently uses one implementation of atomics
and C++ another. We still have to make sure that those two
implementations interoperate correctly at runtime; in particular,
any flavor of atomic object needs to be represented exactly like the
underlying type, with the proper alignment constraint.
Bug:17007799
Change-Id: Iffcfc5220d8fa150f89dd083a121b24d23f268fc
