There were a number of problems with how we updated and handled our cache. First of all, we did not support empty macros that consist only of a single `MACRO_ACTION_END`: we returned immediately as soon as we encountered one such. This is undesirable, we want to support such empty macros. Seconds, we did _not_ bail out early when encountering an unknown step. We continued reading from storage until we reached our slice's end. That's also undesirable, because data past an unknown step is not something we can reliably parse. We should have bailed out here. On top of that, we did not keep our id->location map in good shape. The initial cache update did the right thing, but if we did an update where we ended up with less macros, our map would have dangling pointers for macro ids that no longer exist. That's not a problem when our update clears the rest of the storage slice, but if it doesn't, the results of trying to run an unknown macro would be unpredictable. Even if we don't care about that, it's still very inefficient, especially when we have large macro storage. So, this update does a whole lot of things to improve the situation: We now keep track of how many macros we find during a cache update, and will refuse to play macro ids that are beyond our count. This improves efficiency, and protects us from trying to run garbage. We also support empty macros now, and return early from a cache update when we encounter an unknown step type. Fixes #1177. Signed-off-by: Gergely Nagy <algernon@keyboard.io>pull/1179/head
parent
2dbf0f807b
commit
c0b99d763e
Loading…
Reference in new issue