gh-117031: Add support for arbitrary C integer types for PyMemberDef.type #132550
Conversation
…erDef.type Py_T_INTEGER(type) represents arbitrary C integer type.
serhiy-storchaka
requested review from
gpshead,
AA-Turner and
hugovk
as code owners
|
Hum, I prefer #117032 approach with one member type per C type. |
Misc/NEWS.d/next/C_API/2024-03-19-21-13-20.gh-issue-117031.0s3Ruq.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
|
Thanks @StanFromIreland. |
|
What do you think about using the lower byte for all |
|
Perhaps Py_ASNATIVEBYTES_UNSIGNED_BUFFER can be used without Py_ASNATIVEBYTES_REJECT_NEGATIVE (but not opposite). All other flags do not make sense here. Endianess is always native, there is no reason to not support Question: how to combine this with |
…' into structmember-types2
If you use UNSIGNED_BUFFER without REJECT_NEGATIVE, then you can get data in the most significant bit for a large positive int rather than being guaranteed a sign bit. It's like a normal C cast. Without UNSIGNED_BUFFER but with REJECT_NEGATIVE, you're guaranteed that the top bit is going to be 0, because it must be the sign bit and you'll never have a negative value, so you have 1 fewer bits of data. If a normal C cast is not appropriate here (and I don't think it is), then for unsigned types you'll want both flags and for signed types you'll want neither. |
| {"T_FLOAT", Py_T_FLOAT, offsetof(test_structmembers, structmembers.float_member), 0, NULL}, | ||
| {"T_DOUBLE", Py_T_DOUBLE, offsetof(test_structmembers, structmembers.double_member), 0, NULL}, | ||
| {"T_STRING_INPLACE", Py_T_STRING_INPLACE, offsetof(test_structmembers, structmembers.inplace_member), 0, NULL}, | ||
| {"T_LONGLONG", Py_T_LONGLONG, offsetof(test_structmembers, structmembers.longlong_member), 0, NULL}, | ||
| {"T_ULONGLONG", Py_T_ULONGLONG, offsetof(test_structmembers, structmembers.ulonglong_member), 0, NULL}, | ||
| {"T_CHAR", Py_T_CHAR, offsetof(test_structmembers, structmembers.char_member), 0, NULL}, | ||
| {"T_INT8", Py_T_INTEGER(int8_t), offsetof(test_structmembers, structmembers.int8_member), 0, NULL}, | ||
| {"T_UINT8", Py_T_INTEGER(uint8_t), offsetof(test_structmembers, structmembers.uint8_member), 0, NULL}, | ||
| {"T_XINT8", Py_T_INTEGER(int8_t)|Py_T_INTEGER(uint8_t), offsetof(test_structmembers, structmembers.xint8_member), 0, NULL}, |
There was a problem hiding this comment.
I don't get the use case of this weird type. If you consider that it's important to support it, can you at least document it?
Py_T_INTEGER(type) represents arbitrary C integer type.
📚 Documentation preview 📚: https://cpython-previews--132550.org.readthedocs.build/