gh-148573: correct allocation of complex types in the ctypes

[skirpichev]

Old code relying on implementation detail, that elements[1] for the FFI_TYPE_COMPLEX was never read.

But this type actually shares same assumption as the FFI_TYPE_STRUCT: the elements field is a NULL-terminated array of pointers to ffi_type objects. So far for primitive types - only complex types have this struct field as non-NULL (two element array).

• Issue: _ctypes breaks libffi's NULL-terminated elements invariant for complex types #148573

[sunmy2019]

Should we add news for this?

[skirpichev]

Should we add news for this?

I don't think it's a user-visible change.

[encukou]

Thanks! There's one more check we can do here.

Suggested change

	/* From primitive types - only complex types have the elements
	struct field as non-NULL (two element array). */
	assert(fmt->pffi_type->type == FFI_TYPE_COMPLEX);
	/* From primitive types - only complex types have the elements struct
	field as non-NULL (two element array, including final NULL). */
	assert(fmt->pffi_type->type == FFI_TYPE_COMPLEX);
	assert(fmt->pffi_type->elements[1] == NULL);

[sunmy2019]

If that's needed, how about using the same check in libffi, i.e.

a->elements != NULL && a->elements[0] != NULL && a->elements[1] == NULL

[skirpichev]

I don't think we need this. Actual FFI-invariants are irrelevant for us. The only assumption from our side is that the possible type here is FFI_TYPE_COMPLEX.

[sunmy2019]

I agree it is okay without additional checks, since the behavior here is well documented.
https://github.com/libffi/libffi/blob/10056e7e6a0d40d2a21af63484b99f08898dde9e/doc/libffi.texi#L694

[skirpichev]

Closing, as fix included in #148485.