For another simple example, [buffer-overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation ) could be trivially prevented through the same sorts of checks.

A popular website for programmers, [StackOverflow](https://stackoverflow.com/ ), was named after this sort of thing.

Then there're memory-management errors that could be prevented through automated-memory-management (e.g., [use-after-free](https://en.wikipedia.org/wiki/Dangling_pointer#Security_hole... )), invalid-parameter exploits that could be prevented by parameter-validation, format-exploits that could be prevented by proper encoding (e.g., [SQL injection](https://en.wikipedia.org/wiki/SQL_injection )), etc..

Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either.

A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.