Repository navigation
MAINT: Add a PyDataType_ISUNSIZED macro - #9953
Conversation
7752542 to
50f86da
Compare
This allows us to change how flexible types with no length are represented in future, to allow zero-size dtypes (numpy#8970).
50f86da to
7cfbaf6
Compare
| #define PyDataType_ISOBJECT(obj) PyTypeNum_ISOBJECT(((PyArray_Descr*)(obj))->type_num) | ||
| #define PyDataType_HASFIELDS(obj) (((PyArray_Descr *)(obj))->names != NULL) | ||
| #define PyDataType_HASSUBARRAY(dtype) ((dtype)->subarray != NULL) | ||
| #define PyDataType_ISUNSIZED(dtype) ((dtype)->elsize == 0) |
There was a problem hiding this comment.
This is one of those cases where (0 == (dtype)->elsize) is a bit safer. Many years ago there was an attempt to subvert linux with a bit of trick code someone slipped into the public branch that replaced a check, something like user == 0, by user = 0. Site shutdown and a months long hunt for the attacker's pathway ensued. That said, I don't think this is worth worrying about, it just reminds me when I see it ;)
|
Looks straight forward, so the question becomes, what is the plan for the next step? |
|
One idea would be to change the definition to the C equivalent of |
|
OK, let's get this in. It can't hurt and does set the stage for later mods. |
|
Thanks Eric. |
This allows us to change how flexible types with no length are represented in future, to allow zero-size dtypes (#8970).
Perhaps it would be better to just define
PyDataType_UNSIZEDas zero, rather than havingPyDataType_MAKEUNSIZEDexisting - it implies a level of abstraction that doesn't work, namely that settingdtype->elsizeclears the "unsized" flag.