A warning about signed vs unsigned comparison was converted
into an error here :
...
struct stat st;
if (st.st_size > sizeof(prop_area) {
...
st_size is either an off64_t, which is a signed type. It's
worth investigating why this didn't trigger a warning on 32 bit,
where it's signed as well.
Change-Id: Ib2622bd5c444ddcfa7fb2141f00332cbb4a0818b
This change constitutes the minimum amount of
work required to move the code over to C++, address
compiler warnings, and to make it const correct and
idiomatic (within the constraints of being called
from C code).
bug: 13058886
Change-Id: Ic78cf91b7c8e8f07b4ab0781333a9e243763298c
Also undo some of the mess where we have OpenBSD <stdio.h> but a mix of
different BSD's implementations.
In this first pass, I've only moved easy OpenBSD stuff.
Change-Id: Iae67b02cde6dba9d8d06fedeb53efbfdac0a8cf6
Why do we see so many bogus strict-aliasing warnings? Because we asked GCC to
cause trouble on arm and mips.
Change-Id: I25d7fd036b6afff7ccfa799abe0dc1579ead2847
I screwed up when I originally imported these files; they're in lib/libc/
in the upstream tree; there is no top-level libc/ (though there is a top-level
common/, so those files stay where they are).
Change-Id: I7c5e2224a4441ab0e33616a855a8c6aacfeac46f
Our <machine/asm.h> files were modified from upstream, to the extent
that no architecture was actually using the upstream ENTRY or END macros,
assuming that architecture even had such a macro upstream. This patch moves
everyone to the same macros, with just a few tweaks remaining in the
<machine/asm.h> files, which no one should now use directly.
I've removed most of the unused cruft from the <machine/asm.h> files, though
there's still rather a lot in the mips/mips64 ones.
Bug: 12229603
Change-Id: I2fff287dc571ac1087abe9070362fb9420d85d6d
I broke the mips build yesterday because it doesn't use
<private/bionic_asm.h> like the other architectures, including mips64.
I want to move mips closer to mips64 to try to avoid this kind of thing
in future.
Change-Id: Idb985587ff355b9e5e765c1f5671dc0144cd2488
Turns out stlport isn't broken. <cmath> (included
transitively via gtest in our case) is not required
to make C99 math macros (like signbit) available, nor is
it required to preserve them if they're already defined.
It is only required to make the equivalent functions in
namespace std available.
I couldn't find any documentation of required behaviour for
programs that include both <math.h> and <cmath>.
I've verified experimentally that llvm's libc++ and gnu
stl behave the same as stlport.
bug: 12935307
Change-Id: I9dc5cc0fd9f4f259abc8eefb280177cdd092a94b
