I'm trying out the boost 1.34.0 beta, and there are some warnings of interest. I'm using gcc 4.1 x86/32 (on SuSE 10.1), building boost with "variant=release". There are several occurrences of "dereferencing type-punned pointer will break strict aliasing rules" with locations listed below. libs/iostreams/src/zlib.cpp:108 libs/iostreams/src/zlib.cpp:109 libs/python/src/list.cpp:16 libs/python/src/long.cpp:12 libs/python/src/long.cpp:19 libs/python/src/long.cpp:26 libs/python/src/dict.cpp:32 libs/python/src/tuple.cpp:12 libs/python/src/str.cpp:13 libs/python/src/class.cpp:571 libs/python/src/class.cpp:581 This build of boost is being compiled against Python 2.5. Note that Python 2.5 on this platform builds with gcc's -fno-strict-aliasing option. My personal experiences with strict-aliasing problems with gcc, as well as anectdotal information, leads me to strongly suggest that Boost.Python should also be built with that compiler flag (at least when building in release mode), and that possibly any client wrapper code should do so as well. This is because the Python headers that Boost.Python (and client code) depend on may not be strict-aliasing correct. The result of not being strict-aliasing correct when gcc's strict-aliasing option is enabled (which it is by default for gcc versions starting with 4.0?) is that the compiler may generate code which is (often quite subtly) broken. (A couple of weeks ago I ran afoul of this problem with a different library, where gcc's warnings were a false negative (i.e. no warning) and just silently generated non-working code if strict-aliasing was enabled. I'm presently looking at diffs in the generated assembly code (not fun) because I haven't been able to find the problem by looking at the source.)