Add "-fno-strict-aliasing" to compilation flags
Fixes a slew of: "dereferencing type-punned pointer will break strict-aliasing rules" warnings from GCC for lines of the form: Py_INCREF(Py_True); and Py_INCREF(Py_False);
due to the cast from PyIntObject* to PyObject*
GCC is technically correct here; see: http://www.python.org/dev/peps/pep-3123/ though this is unlikely to lead to non-working machine code.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/924
-- Commit Summary --
* app_python: fix compiler warning
-- File Changes --
M src/modules/app_python/Makefile (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/924.patch https://github.com/kamailio/kamailio/pull/924.diff
Not really using app_python, but still sort of don't like adding the "-fno-strict-aliasing" because it can hide bugs in other parts of module code, but if that's the only way as detailed in pep 3123 and nobody else finds a different solution, then can be merged.
On Alpine linux app_python cannot be compiled with python3 but can with python2 Questions - is issue will be resolved when update module to use python3?
Merged #924.
@sergey-safarov unfortunately no. Python3 is different in initialization, data and type structures and so on. I plan to add Python3 support to the module but unfortunately I haven't any free time to do that...
@ezdev128 - any specific reason for this merge without clarifying the `-fno-strict-aliasing` concerns?
@miconda because I think it's a better way for now, py2 has the int types for boolean, py3 is not, this is a cause of. I have the same fix for some months in production. I did many changes in current code but it's dirty and under NDA (for one customer). As soon I will have free time - I will clean the code and push big commit to resolve current problems, python3-compability and other bugfixes.
@ezdev128 - the concern is that by doing this hack just to **not see** some known warnings due to external code, you hide eventual strict aliasing issues in the kamailio module code, so if one adds new code and mixes pointer types, it won't be any earning. This can cause unpredictable troubles at runtime.
Anyhow, as I said in my previous comment, I am not using the module and if people other devs want it with this one, it's ok for me. But simply merging a PR with expressed concerns in comments without any details is not that good approach.