In numpy/f2py/capi_maps.py, the three type-mapping dicts handle complex_long_double inconsistently:

# c2capi_map (lines ~71-75) — used to select the NumPy C API dtype
'complex_double':      'NPY_CDOUBLE',
'complex_long_double': 'NPY_CDOUBLE',   # same as complex_double — precision silently lost?

# c2pycode_map (lines ~91-93) — used to build Python format strings
'complex_double':      'D',
'complex_long_double': 'G',             # distinct code

# c2buildvalue_map
'complex_double':      'N',
'complex_long_double': 'N',             # same

c2pycode_map assigns 'G' to complex_long_double, implying the type is recognised as distinct. But c2capi_map maps it to the same NPY_CDOUBLE as complex_double.

Compare with real types: long_double correctly maps to NPY_LONGDOUBLE, preserving extended precision. There is no corresponding NPY_CLONGDOUBLE mapping for the complex counterpart.

Questions:

1. Is the downcast of complex_long_double → NPY_CDOUBLE intentional (e.g. no platform-portable complex-long-double C API type exists)?
2. If intentional, should a warning be emitted when f2py wraps a Fortran COMPLEX*32 or similar to alert users to the precision loss?
3. Should the three maps be audited for consistency, or is the divergence between c2capi_map and c2pycode_map load-bearing?

File: numpy/f2py/capi_maps.py