event.key.keysym.sym is of the type SDL_Keycode which is essentially a signed 32-bit integer. I’m assuming that bKeysHeld is a fixed size array that doesn’t have the space to hold a billion+ entries (that would be very silly). The left shift key has the value SDLK_LSHIFT, which is done with a macro on the SDL_Scancode going by the name SDL_SCANCODE_LSHIFT (with a value of 225). The macro SDL_SCANCODE_TO_KEYCODE sets the second highest bit (highest non-sign bit) to 1 and ORs this with the scancode, producing the expression (1 << 30) | 225 which has the value 1073742049 or just over a billion. This means you’re trying to write to a location that is around 4GiB past the start of your array, resulting in a buffer overflow.
If you want similar semantics to what you’re currently doing, you could for instance use a hash map of booleans instead of an array, or a hash set of keysyms where you either add or remove entries as you come across key events.
I don’t get it works fine for the smaller buttons, I found this.
" The value of event.key.keysym.sym is wrong for sdl.SDL_KEYDOWN/sdl.SDL_KEYUP events on ARM64/postmarketOS/sdl2-2.0.12-r1. For example, this is what I get for a t key: 1073742095, when it should be 116 according to SDL_keycode.h.
This is on an ARM64 device running postmarketOS (based on Alpine Linux) with sdl2-2.0.12-r1. It works fine on my Fedora 32 x64 machine with its SDL2 2.0.12-1.fc32, so I do wonder if this is a bug with PySDL2’s assumption of how the event struct is laid out on ARM64 platforms? At least that is my best guess as to what the issue could be.
Edit: also yes, that means all key input other than SDL_TEXTINPUT is currently unusable on that platform which is a bit of a shame"