A theory for decades of C vulnerabilities
The central argument is that C's memory vulnerabilities stem from broken semantic invariants—properties about values that must hold for correct operation but aren't enforced by the type system. This explains integer overflow, buffer overflow, use-after-free, and double free as different manifestations of the same underlying failure, where the program's representation of reality ceases to correspond to reality.
The vulnerability is the point at which the program's representation of reality ceases to correspond to reality.
- titzer
> A substantial portion of the initial manuscript was generated with the assistance of artificial intelligence. The author provided the underlying concept and creative direction and worked extensively with AI tools throughout the development of the book, selecting, restructuring, editing, rewriting, and refining the material. The final book reflects the author’s creative vision and editorial decisions.
I'm wondering how the author convinced the AI to forget about decades of prior work on describing programming language implementation and produce a work that seems to have no prior art.
- hackthemack
I had similar? thought many years ago when strong typing became another one of the programming mantras touted on the internet.
Even dynamically type programming languages will layout what types the languages has. But that is usually the conventions built off of years of history, usually based on C.
But what if you wanted to define a custom type to use? Say you wanted to make type mysmallint, and it was an integer that is between 1 and 1000. Now, you can write up code to do this but it is not the same thing as declaring type int. *
*unless you are using Haskell, F#, or others I am not aware of.
What if you wanted to define a custom type that says this string only contains ascii characters? You can not easily define that as a type and pass it around the code. You have to write custom code and do checks.
- jakeinspace
Can't really have it all. If you want runtime assertions on your data/state, that has a cost. Nothing is stopping you from writing that logic out and having all your inputs and outputs sanitized for "semantic invariance". But if you want the language to implicitly do that, you're gonna have overheads. Pick a different systems language in that case, and deal with the tradeoff.