distutils and -fno-strict-aliasing

[Jakub Wilk <jwilk@debian.org>]

I noticed a bug/feature of Python 2.7 (and 3.X) distutils that worries 
me a bit. Let's try to compile a simple extension module:

$ python2.7 setup.py build_ext | grep -F .c
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c markupsafe/_speedups.c -o build/temp.linux-x86_64-2.7/markupsafe/_speedups.o

Everything looks fine until we put some build flags into environment (if 
we were building a Debian package, dpkg-buildpackage would do that for 
us):

$ eval $(dpkg-buildflags --export=sh)
$ rm -Rf build/
$ python2.7 setup.py build_ext | grep -F .c
gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -fPIC -I/usr/include/python2.7 -c markupsafe/_speedups.c -o build/temp.linux-x86_64-2.7/markupsafe/_speedups.o

Please note that "-fno-strict-aliasing" is no longer passed to gcc. I 
believe C extensions quite often exploit type punning that breaks strict 
aliasing rules, so omitting -fno-string-aliasing has a great potential 
for breakage.

My question is: is this is a bug in python2.7/python3.X? Or are we 
supposed to fix (all) the extensions that are built via distutils?

--
Jakub Wilk