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
Using enums in a C ABI can make it harder for non-C languages to cooperate, as they have to find out the enum bitwidth when implementing the ABI. Granted, the enum bitwidth is normally set by the platform ABI, but people still have to find that information and perhaps write platform-specific code to handle it correctly. Using explicitly-sized ints (such as int32_t etc.) instead of enum-typed struct fields would avoid that issue.
FTR, x86-64, which I assume is the dominant platform for DLPack, mandates 32-bit integers for enums both on the "SysV ABI" (used by Linux, macOS...) and Windows. So, doing this change while minimizing potential breakage would probably require adopting int32_t fields in structs where enum fields where used.
(this does not forbid the existence of an enum declaration in the C header, btw; just in struct fields)
The text was updated successfully, but these errors were encountered:
Using enums in a C ABI can make it harder for non-C languages to cooperate, as they have to find out the enum bitwidth when implementing the ABI. Granted, the enum bitwidth is normally set by the platform ABI, but people still have to find that information and perhaps write platform-specific code to handle it correctly. Using explicitly-sized ints (such as
int32_t
etc.) instead ofenum
-typed struct fields would avoid that issue.FTR, x86-64, which I assume is the dominant platform for DLPack, mandates 32-bit integers for enums both on the "SysV ABI" (used by Linux, macOS...) and Windows. So, doing this change while minimizing potential breakage would probably require adopting
int32_t
fields in structs whereenum
fields where used.(this does not forbid the existence of an
enum
declaration in the C header, btw; just in struct fields)The text was updated successfully, but these errors were encountered: