When the python bindings are installed using the new wheels
infrastructure, data_files are relative to the site-packages directory
even if using absolute paths.
The following example demonstrates the bug fixed by this commit: (ran on archlinux)
```bash
$ pip install wheel # if this package is installed, wheel installation is made the default
Collecting wheel
Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
100% |################################| 71kB 124kB/s
Installing collected packages: wheel
Successfully installed wheel-0.29.0
$ pip install capstone # this will use the wheel installation method now
Collecting capstone
Using cached capstone-3.0.4.tar.gz
Building wheels for collected packages: capstone
Running setup.py bdist_wheel for capstone ... done
Stored in directory: /root/.cache/pip/wheels/7c/d1/d0/db6e2c5ef1063aabb9de2dd8b92b4c27ee6f9fd213240099b8
Successfully built capstone
Installing collected packages: capstone
Successfully installed capstone-3.0.4
$ find /usr/lib/ -name "libcapstone.so"
/usr/lib/python3.5/site-packages/usr/lib/python3.5/site-packages/capstone/libcapstone.so
```
So the path `SITE_PACKAGES` in the `data_files` specification of the
setup.py file was interpreted relative to the python site-packages
directory. The fix for this is simple: use `/capstone` instead of an
absolute path for `SITE_PACKAGES`.
It should be unsigned because:
* It does arithmetic operations
* Format strings have "%u" instead of "%d"
# Conflicts:
# arch/ARM/ARMInstPrinter.c
# bindings/python/test_arm.py
# tests/test_arm.c
Comparing against 0 or just testing the truthiness is suboptimal, as you
lose the ability to explicitly set the syntax to CS_OPT_SYNTAX_DEFAULT
or 0.
Also, using None to mean "don't change" or other "here is no value"
interpretations is much more pythonic than the C-idiomatic 0.
* Fixed a break indentation
* Fixed incorrect enum value for M68K_GRP_IRET
* Fixed so groups_count is set to 0 at init
* Added group_count printing in python example
