5 ms·
Nitpick: With memory (un)safety, a crash is the optimal outcome when something goes wrong. The real problem is when it doesn't crash and the program continues o
by ChrisSD 5y ago
Nitpick: With memory (un)safety, a crash is the optimal outcome when something goes wrong. The real problem is when it doesn't crash and the program continues on thinking everything is fine...
- memco 5y agoI'm quite amazed how resilient games are to this. Like how SMB1 for the NES is capable of things like the minus worlds where you're more or less playing levels that don't exist because the game doesn't expect you to be reading memory past a certain point, but as long as the values are valid, it can still use it to some degree. There's more extreme situations like Super Mario Land 2 for the Game boy where it's possible for the game to present it's own memory on the screen and if you understand how it works you can do things like ask the game to execute the ending sequence [0]. At it's most extreme a series of TASes was presented in 2017 wherein multiple different hardware systems were linked together via RCEs in different games to make a VOIP streaming setup from a bunch of consoles that don't actually have internet connections [1]. I'm sure there's all kinds of reasons this kind of UB is undesirable, and could be hazardous in some environments, but people have also done some really cool stuff with it! [0]: https://www.youtube.com/watch?v=faiZgO35YaQ&t=0s https://www.youtube.com/watch?v=faiZgO35YaQ&t=0s [1]: https://www.youtube.com/watch?v=7CgXvIuZR40 https://www.youtube.com/watch?v=7CgXvIuZR40
- pcwalton 5y agoThe resilience is because (1) those titles ran on systems with no MMUs; (2) there was no heap and no malloc implementation, therefore no way to get use-after-free. None of these points apply to modern systems, including consoles.