You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry, overlooked this issue.
However, I don't really understand what you mean. Do you mean that, for ABI stability, we should use fixed-width types like uint64_t or similar?
We should not have enum nor 'long' in publicly-facing API, since thy are not well defined. Something like uint64_t would be preferable, and would align the struct.
Agreed. IIRC, we used unsigned long for flags since we first tried to make our struct compatible with CPython's PyType_Spec but we dismissed that anyway.
For the enum, we basically didn't think about that. An enum just seemed to be the right thing since there is a limited set of valid values.
Currently HPyType_Spec uses
HPyType_BuiltinShape
which is anenum
andlong
in its typedefhpy/hpy/devel/include/hpy/hpytype.h
Line 102 in f611473
hpy/hpy/devel/include/hpy/hpytype.h
Line 131 in f611473
These are ambiguous since
enum
does not have to beint
andlong
is 4 bytes on windows but 8 everywhere else.Also the struct is not aligned, it needs padding around the
HPyType_BuiltinShape
to align on 8 bytes.The text was updated successfully, but these errors were encountered: