I am aware that this file went through many iterations and complex support is a constant headache, and if there is any more appetite left, I'd like to offer another minor change.

We have been having some warnings coming from non-C99-compliant compilers and C++ runs over SciPy since NumPy 2.0. This is mainly due to the npy_crealX/npy_cimagX functions, casting the input struct first and then dereferencing it in the new type, causing the strict-aliasing (type punning) rule to fire.

Here is a recent example how this manifests itself in the build process https://github.com/scipy/scipy/actions/runs/14770722795/job/41470198162#step:6:300

[snip]
 In file included from ..\scipy\_build_utils\src/npy_2_complexcompat.h:4,
                 from ../scipy/special/xsf_wrappers.h:13,
                 from ../scipy/special/xsf_wrappers.cpp:1:
C:\hostedtoolcache\windows\Python\3.12.10\x64\Lib\site-packages\numpy\_core\include/numpy/npy_math.h: In function 'npy_longdouble npy_creall(npy_clongdouble)':
C:\hostedtoolcache\windows\Python\3.12.10\x64\Lib\site-packages\numpy\_core\include/numpy/npy_math.h:422:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  422 |     return ((longdouble_t *) &z)[0];
      |            ~^~~~~~~~~~~~~~~~~~~~ 
[snip]

I don't know if the SciPy code is also commiting some C++ sins but the NumPy code can do better to avoid strange bugs. I don't claim to have the right solution but seems like the most obvious one to me to let the compiler handle the possible padding/endianness issues with a straight struct field access. However I don't have a strong opinion since I'm not a C++ expert.

This is also somewhat related to our ambition to be warning free at some point.