On Friday 09 October 2009, Matteo Frigo wrote: > Your bug report implies that calling fftw from a program that > #include's <complex.h> causes a violation of the aliasing rules, > because fftw is compiled with fftw_complex = double [2] and the > program is compiled with fftw_complex = double _Complex. I contend > that no incorrect behavior can possibly occur in this situation, and > your example does not contradict my contention. Indeed, each > translation unit is itself well typed and has no aliasing violations. > We take the liberty across translation-unit boundaries to reinterpret > pointers to double _Complex as pointers to double [2], which is legal > because the two types are guaranteed to have the same representation.
And this assertion is based on what? There is no exception in the strict aliasing rules about aliasing that occurs across translation unit boundaries. Whether or not such aliasing is safe is entirely dependent on implementation-defined behavior, the standard leaves it undefined. Linkers perform optimizations too, and compilers like LLVM can even do run-time optimization and cross-module optimization. There is nothing in the standard prohibiting cross-translation-unit optimizations that exploit the language's strict aliasing rules. Also, we haven't even got to violations of the "one definition rule" from C++ in programs unfortunate enough to use fftw_complex like it was a genuine type. The ill-defined nature of fftw_complex can easily produce link errors, errors in function overloading, and errors in template specializations when compiling with g++. However, I'm clearly making absolutely zero progress in convincing you there is anything wrong with this "feature" of fftw. It's your library, do with it what you will.
signature.asc
Description: This is a digitally signed message part.
