We don't actually need to worry about sign extension if we reject
negative values ourselves. Previously it was possible to come up
with negative but aligned values that we would pass to the kernel;
in the case of mmap (as opposed to mmap64) we'd incorrectly turn
those into large positive offsets.
Change-Id: I2aa583e0f892d59bb77429aea8730b72db32dcb0
The various committees decided that everyone should get all these macros,
all the time.
Bug: 12708004
Change-Id: Ib56010dcba9b0656e5701546fefb7f78dc0bf916
This is required to make the Nexus 10 graphics driver work on a system
compiled with gcc 4.9.
Change-Id: If3f3d488652a736d9ea3e583548d74fae3ffa902
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
These functions should print assertion violation messages and then
call abort(). They do really not return control flow afterwards.
Consider the declaration of the similar __assert_fail from glibc:
extern void __assert_fail (const char *__assertion,
const char *__file,
unsigned int __line,
const char *__function)
__THROW __attribute__ ((__noreturn__));
Bionic has __noreturn defined in sys/cdefs.h to be that GNU
noreturn attribute.
This patch has a practical value. Consider the following function:
void check(void* ptr) {
assert(ptr != NULL);
}
Without this patch applied, gcc (and presumably clang) shows even in
debug mode:
warning: unused parameter 'ptr' [-Wunused-parameter]
In release mode, NDEBUG is defined and assert() becomes a no-op, as
one should expect. Thus, the warning is shown correctly then.
Another code sample:
float array[2];
int i = 3;
...
assert(i < 2);
array[i] = 0;
gcc says,
warning: array subscript is below array bounds [-Warray-bounds]
In other words, without noreturn attribute, assertions do not
allow a compiler's static analyzer to properly understand
the preconditions.
Change-Id: I3be92e99787c528899cf243ed448c4730c00c45b
Signed-off-by: Vadim Markovtsev <gmarkhor@gmail.com>
This patch adds trivial implementations of the missing sys headers
needed by strace. All strace needs are the constants and structures,
so this is enough for now. We can come back and add the functions
if/when we ever need them.
Change-Id: Idb87c1a8b6b1c62f6e16ae94f147e1169722b48e
The situation here is a bit confusing. On 64-bit, rlimit and rlimit64 are
the same, and so getrlimit/getrlimit64, setrlimit/setrlimit64,
and prlimit/prlimit64 are all the same. On 32-bit, rlimit and rlimit64 are
different. 32-bit architectures other than MIPS go one step further by having
an even more limited getrlimit system call, so arm and x86 need to use
ugetrlimit instead of getrlimit. Worse, the 32-bit architectures don't have
64-bit getrlimit- and setrlimit-equivalent system calls, and you have to use
prlimit64 instead. There's no 32-bit prlimit system call, so there's no
easy implementation of that --- what should we do if the result of prlimit64
won't fit in a struct rlimit? Since 32-bit survived without prlimit/prlimit64
for this long, I'm not going to bother implementing prlimit for 32-bit.
We need the rlimit64 functions to be able to build strace 4.8 out of the box.
Change-Id: I1903d913b23016a2fc3b9f452885ac730d71e001
glibc has no <sys/dirent.h>. If we do have to bring this back, we
should probably just have one file #include the other.
Change-Id: I5c0bf9c03769daf3b23f69778e9f01f81c3de9ec
If glibc hadn't already done things this way round, I'd have
called the field sched_priority and the macro __sched_priority
since that would seem less likely to cause trouble, but glibc
source compatibility is probably more important.
Change-Id: I8a8a477f2aa87cae641069c5c84b4fcab3152a82
Modify the syscalls script to generate the cfi directives for x86
syscalls.
Update the x86 syscalls.
Change-Id: Ia1993dc714a7e79f917087fff8200e9a02c52603
Adds the TCPOPT_* constants from NetBSD. Note that the BSDs also have
TCPOPT_SIGNATURE, but Linux calls that TCPOPT_MD5SIG and glibc doesn't
have any corresponding constant yet, so let's wait until we see which name
wins out.
Change-Id: If53cdada5595285d9a7e7248ef74cd7502d804c0
32-bit Android's dev_t was wrong too. We can't fix that without ABI breakage,
but we can at least fix 64-bit Android. And add tests.
Bug: https://code.google.com/p/android/issues/detail?id=54966
Change-Id: Ie2e42cc042b78b669a1a44e55f959dbd9c52c5c9
This patch switches to using the uapi constants. It also adds the missing
setns system call, fixes sched_getcpu's error behavior, and fixes the
gensyscalls script now ARM is uapi-only too.
Change-Id: I8e16b1693d6d32cd9b8499e46b5d8b0a50bc4f1d
