~vanvugt/mir/bind-result

Viewing all changes in revision 1757.

  • Committer: Tarmac
  • Author(s): Alexandros Frantzis
  • Date: 2014-07-09 21:50:38 UTC
  • mfrom: (1756.1.1 fix-gcc-4.9-build)
  • Revision ID: tarmac-20140709215038-8sv79unhcx0vzqq1
android,tests: Fix g++ 4.9 build

It seems that g++-4.9 has become more aggressive about constant folding of
expressions that use sizeof(), thus triggering warnings/errors related to
constant overflows that didn't occur with g++-4.8.

For example, g++-4.8 warns about overflowing i3, but not i4, whereas g++-4.9
warns about both i3 and i4: 

#define VALUE1 0x70000000UL
#define VALUE2 (VALUE1 >> sizeof(unsigned char))
#define VALUE3 0x80000000UL
#define VALUE4 (VALUE1 << sizeof(unsigned char))

int main()
{
    int i1 = VALUE1;
    int i2 = VALUE2;
    int i3 = VALUE3;
    int i4 = VALUE4;
}

This affects our ioctl() wrapper calls because we use 'int' for the request
parameter, whereas the request numbers produced by the kernel macros (using
sizeof() in the calculation) are 'unsigned long'. This MP fixes the problem by
casting the request numbers to 'int', which is a safe conversion since the 
request numbers are constrained to 32 bits by design.

Note that we don't have a problem with all ioctl request numbers, although they
are produced by the same set of macros, because almost all of them don't have
the high bit set (like VALUE2 above) and don't trigger the overflow error. The 
one we have a problem with, SYNC_IOC_MERGE, has the high bit set (like VALUE4
above).

Also note that the glibc ioctl() function signature uses 'unsigned long'
instead of 'int' for the request number. So, alternatively, we could fix the 
problem by changing our wrappers to use 'unsigned long', too. However, the 
glibc signature goes against POSIX and there have been discussions about
switching it back. See https://sourceware.org/bugzilla/show_bug.cgi?id=14362 .

Approved by Kevin DuBois, PS Jenkins bot, Alan Griffiths.

expand all expand all

Show diffs side-by-side

added added

removed removed

Lines of Context: