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
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
These names were pretty misleading (aka "backwards"), so switch to the
same obvious names glibc uses.
Test: build.
Change-Id: Ia98c9dbbccd0820386116562347654e84669034a
Just expose the ones that bionic historically leaked.
Also, many of the M_* constants in <math.h> are actually POSIX.
Change-Id: I6275df84c5866b872b71f1c8ed14e2aada12b793
This seems to be obsolete BSD stuff, and the only references to it in the
tree are people #undef'ing it.
Bug: http://b/2735009
Change-Id: Icde523ae2d15cf1025357d861f97b415e89e4f9a
Use the upstream OpenBSD implementations of these functions.
Also ensure we have symbols for htonl, htons, ntohl, and ntohs.
gtest doesn't like us using the macro versions in ASSERT_EQ.
Bug: 14840760
Change-Id: I68720e9aca14838df457d2bb27b999d5818ac2b5
Most of <machine/_types.h> was either unused, wrong, or identical across
all 32-/64-bit architectures.
I'm not a huge fan of <sys/_types.h> either, but moving the bits we need
up into there is a step forward.
Bug: 12213562
Change-Id: Id13551c78966e324beee2dd90c5575e37d2a71e6
Previously we'd been relying on getting the machine-specific <endian.h>
instead of the top-level <endian.h>, and <sys/endian.h> was basically broken.
Now, with this patch and the previous patch we should have <endian.h>
and <sys/endian.h> behaving the same. This is basically how NetBSD's endian.h
works, and was probably how ours was originally intended to work.
Bug: http://code.google.com/p/android/issues/detail?id=39824
Change-Id: I71de5a507e633de166013a658b5764df9e1aa09c
Elliott Hughes
Colin Cross
Josh Gao
The Android Open Source Project