gh-148464: Add missing __ctype_le/be__ attributes for complex types in the ctype module#148485
gh-148464: Add missing __ctype_le/be__ attributes for complex types in the ctype module#148485skirpichev wants to merge 13 commits intopython:mainfrom
__ctype_le/be__ attributes for complex types in the ctype module#148485Conversation
…ex types in the ctype module
226aaab to
1e45180
Compare
| D_get_sw(void *ptr, Py_ssize_t size) | ||
| { | ||
| assert(NUM_BITS(size) || (size == 2*sizeof(double))); | ||
| return PyComplex_FromDoubles(PyFloat_Unpack8(ptr, PY_BIG_ENDIAN), |
There was a problem hiding this comment.
Could you add error handling for the unpacks here and PyFloat_Unpack4 below?
if (x == -1.0 && PyErr_Occurred()) {
I'd be happier if ctypes didn't rely on an undocumented implementation detail here.
There was a problem hiding this comment.
Why undocumented? It's documented and widely used across the CPython codebase, e.g. in same file.
There was a problem hiding this comment.
widely used
Well, that's a little lie. But it indeed was used in this way in the ctypes and some other places. Until v3.15.0a8 that was a bug.
It probably not worth to change other places, where error checks kept. But I don't see good reasons to not rely on documented behavior for new code.
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).
|
BTW, the |
Co-authored-by: sunmy2019 <59365878+sunmy2019@users.noreply.github.com>
Co-authored-by: sunmy2019 <59365878+sunmy2019@users.noreply.github.com>
Co-authored-by: sunmy2019 <59365878+sunmy2019@users.noreply.github.com>
Co-authored-by: sunmy2019 <59365878+sunmy2019@users.noreply.github.com>
__ctype_{be,le}__attributes missing forctypes.c_*_complextypes #148464