| Summary: | SDL_Event type fields should be explicitly typed to SDL_EventType instead of Uint32 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | David Farler <accumulator> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | REOPENED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | computers57, philipp.wiesemann |
| Version: | 2.0.3 | ||
| Hardware: | x86 | ||
| OS: | All | ||
| Attachments: |
Add SDL_ENUM and SDL_OPTIONS
Add SDL_ENUM and SDL_OPTIONS, more aggressively Even more aggressive SDL_ENUM and SDL_OPTIONS Add SDL_ENUM and SDL_OPTIONS, more aggressively v2 |
||
Enumerations might have different sizes depending on the C/C++ compiler. Just changing Uint32 to SDL_EventType now might therefore break existing programs. I don't think the effect will be noticeable. GCC x86_64 on Linux defaults to size 4 and clang x86_64 on both Linux and Darwin also default to size 4 for typedef enum, so it shouldn't have a large effect on the body of SDL programs written today. Perhaps some sort of macro to set the enums size, like what OS X does with CF/NS_ENUM and CF/NS_OPTIONS would help. The macro does have it so, on unsupported compilers, the enum values are just enums. The following is what I did for my own project: #ifdef __APPLE__ #include <CoreFoundation/CFBase.h> #define MADENUM CF_ENUM #define MADOPTIONS CF_OPTIONS #else #ifndef __has_feature #define __has_feature(x) 0 #endif #ifndef __has_extension #define __has_extension(x) 0 #endif #if (__cplusplus && __cplusplus >= 201103L && (__has_extension(cxx_strong_enums) || __has_feature(objc_fixed_enum))) || (!__cplusplus && __has_feature(objc_fixed_enum)) #define MADENUM(_type, _name) enum _name : _type _name; enum _name : _type #if (__cplusplus) #define MADOPTIONS(_type, _name) _type _name; enum : _type #else #define MADOPTIONS(_type, _name) enum _name : _type _name; enum _name : _type #endif #else #define MADENUM(_type, _name) _type _name; enum #define MADOPTIONS(_type, _name) _type _name; enum #endif #endif It makes it so that, for instance, my error enum can be defined as `typedef MADENUM(short, MADErr)` and it will come through on Swift as an enum, and still be usable in C/C++ code. Although other compilers might not still have the same enum size. Hello, and sorry if you're getting dozens of copies of this message by email. We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc. Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report. So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues. (please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!) Thanks, --ryan. (In reply to C.W. Betts from comment #3) > Perhaps some sort of macro to set the enums size, like what OS X does with > CF/NS_ENUM and CF/NS_OPTIONS would help. The macro does have it so, on > unsupported compilers, the enum values are just enums. > > [...] > > It makes it so that, for instance, my error enum can be defined as `typedef > MADENUM(short, MADErr)` and it will come through on Swift as an enum, and > still be usable in C/C++ code. > > Although other compilers might not still have the same enum size. Looking back, I can see some inaccuracies in this comment, mainly that the typedef'd type would be an unsized enum: It would preprocess it so the 'MADErr' declaration would be 'typedef short MADErr'. Created attachment 3278 [details]
Add SDL_ENUM and SDL_OPTIONS
This patch add SDL_ENUM and SDL_OPTIONS and incorporates it into a few enums: If they're a bit-mask, I marked them with SDL_OPTIONS. Otherwise, I marked them with SDL_ENUM.
SDL_ENUM that takes one argument just sets the size of the enclosed enums. SDL_ENUM that takes two arguments takes the name and adds it to its type.
If I didn't know the size of the enum, I just used int. I did name some enums, but left some alone.
Just attached a patch that would make a lot of the enums be sized. Created attachment 3282 [details]
Add SDL_ENUM and SDL_OPTIONS, more aggressively
This adds more SDL_ENUMs and SDL_OPTIONS, some of them from macros.
Created attachment 3284 [details]
Even more aggressive SDL_ENUM and SDL_OPTIONS
This patch contains BREAKING changes that take advantage of SDL_ENUM and SDL_OPTIONS in more places.
Created attachment 3301 [details]
Add SDL_ENUM and SDL_OPTIONS, more aggressively v2
Add SDL_ENUM and SDL_OPTIONS, more aggressively
This adds more SDL_ENUMs and SDL_OPTIONS, some of them from macros.
|
Importing the SDL2 framework into the FFI of strongly typed languages such as Swift, the `type` field of the SDL_Event union may not line up with the `typedef enum SDL_EventType`. They may happen to have the same type in C, but that representation may not carry over into the host language. As an example in Swift, SDL_EventType's enum cases are imported as static constants of type SDL_EventType: var SDL_QUIT: SDL_EventType { get } But you can see that SDL_CommonEvent has: struct SDL_CommonEvent { var type: Uint32 var timestamp: Uint32 init() init(type: Uint32, timestamp: Uint32) } This makes certain API uses cumbersome, where one would like to type this: switch event.type { case SDL_QUIT: ... case SDL_KEYDOWN: ... } You have to type this: switch SDL_EventType(event.type) { case SDL_QUIT: ... case SDL_KEYDOWN: ... } This isn't really necessary, we just need a little bit of correct type information for these fields. Where there is `Uint32 type` for the events, there should be `SDL_EventType type` instead. This should be a nonfunctional change for C-family languages and would be imported correctly into other strongly typed languages.