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 thenpy_crealX/npy_cimagX functions, casting the inputstruct 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 processhttps://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: Infunction'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.