Karl Wette authored Feb 13, 2012 and Adam Mercer committed Feb 27, 2012

 * A ./configure macro checks that memory layout of C99/C++ complex types
   are identical to the old LAL complex structs. If true, each .c file can
   then chose which complex datatype to use - C99 or LAL - while being
   able to call code defined in another .c file which may have used a
   different complex datatype internally.
 * If LAL_USE_OLD_COMPLEX_STRUCTS macro is not defined (i.e. by default),
   use C99 complex datatypes. Define macros for constructing C99/C++
   complex numbers, and accessing/assigning real and imaginary parts.
   Macros use some GCC extensions where available.
Original: ba26dab7e236328ebe597d8be7320d21c5be67eb

Original: 3f06f47c332bdf701d4b1805a65a6f8b819ec6b0

Original: e65217d37c43ee8eae41ce2a5d467ebf05ba31e9

- mostly defined using RCSID() and NRCSID() macros
Original: 4aa66bf0a7da3ec0bd82fc5a82ba3424cf5566a1

- swiglal-common.i: C++ function templates swiglal_from
  and swiglal_as_val convert primitive C types to/from
  scripting language, and fall back to make a swig_type
  wrapper for any other type. e.g. structs. All C integer
  and floating-point types, and LAL/GSL complex types are
  considered primitive.
- LALAtomicDatatypes.h: exclude COMPLEX8/COMPLEX16 from
  interface, since they should be always converted to
  scripting language complex numbers.
- swiglal-octave.i: provide SWIG UTL conversion fragments for
  LAL/GSL complex types. octcomplex.swg is broken, so include
  a fixed copy here.
- swiglal-python.i: provide SWIG UTL conversion fragments for
  LAL/GSL complex types.
- Added tests of complex number conversions for Octave and Python
Original: e594e1660cff7c767a96066359b1e3d7195b28a2

it is now safe to assume that floats are 4 bytes and doubles are 8 bytes
Original: 1fb36db3e9d7c7c6a717e80a85ad2cc67fac5dc5

the LAL integer datatypes are now typedefs to the standard width integer
data types from stdint.h, therefore requiring a c99 compliant system
Original: d7b084e16c5a2bb861d0cb0506f2a90ecfc924c1

LAL is no longer built for running within LDAS so the ifdef surrounding
the definition of the LDAS compatible atomic datatypes has been removed
Original: 861b0f571d81ff965068fb678c8478b713c6f713

Original: c779d45a186415bf16fc968fbc124eef22307c70

Original: cdd729b5871d00064211ebe5b09af8cfd8f282b5

Original: 28d810b1666c71a6dc7cc51f071e8846d15ef5d2

Original: e427f38e105cfff39d502e1d6dc150ad36fbd70a

-pedantic to the GCC flags.
Original: f643a29b0bbc496c5295cacfba4cbd36220d6c31

Original: 535a480c9098a33b564a647b35f1ddd93975d886

Original: 0ba4186b7d8cfce986e1f728d345afd6aaeba57b

Original: 77e9af9a0aa3a4acf5cd383e7349aea0d37d2fd8

Original: e48bf771b557fafe16c9ad79082c5ce10bda36b6

included in LALDatatypes.h.
Original: 4fa986929fc58ce441c880e0bf1b0b513714179e