> Frank Hess wrote:
>
> > This means if a user doesn't include fftw3.h first, before any
> > possible inclusion of complex.h, then his code may be using a
> > different ABI than that of the libfftw3.so provided by debian.
This is false. [N843, 6.2.5 Types, verse 13]:
Each complex type has the same representation and alignment
requirements as an array type containing exactly two elements of
the corresponding real type; the first element is equal to the real
part, and the second element to the imaginary part, of the complex
number.
Note that we changed the complex number definition from fftw2 (struct
{ double re, im }) to fftw3 (double [2]) precisely to be compatible
with the (at the time) upcoming c99 standard.
> > Or, indeed, different translation units of the user's program may
> > be using different definitions of fftw_complex depending on
> > exactly when each translation unit included fftw3.h. This will at
> > the very least cause violations of the C strict aliasing rules
> > which can cause mysterious crashes when optimization is turned on
> > (unless gcc's -fno-strict-aliasing option is used). I have
> > personally seen these crashes, and the problems can also be
> > visible when using valgrind (I saw it cause various uninitialized
> > memory problems in my program which valgrind reported).
If so, gcc is broken (but I'd still like to see a test program).
Since the standard clearly implies that one can treat a c99 complex
number as an array of two reals, e.g. by taking the address of the
real part as a double *, a conforming compiler cannot possibly treat
the two cases differently.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
