A theory for decades of C vulnerabilities
strawberry9.github.io
A theory for decades of C vulnerabilities
1–10 of 24 posts
Re: A theory for decades of C vulnerabilities
#2[deleted]
Re: A theory for decades of C vulnerabilities
#3I 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.
Re: A theory for decades of C vulnerabilities
#4Sorry but, ain't we tired of beating that dead horse again and again? We got it, C is a portable assembler and as such, is barely more "secure" than assembler. And yes, 50 years after C you finally have something as fast as it and more secure, congratulations.
Re: A theory for decades of C vulnerabilities
#5Can'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.
Re: A theory for decades of C vulnerabilities
#6[flagged]
Re: A theory for decades of C vulnerabilities
#7> 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.
Re: A theory for decades of C vulnerabilities
#8Can'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.
The author makes reference to making these invariants expressable via the type system, a compile time overhead, not a runtime overhead.
Re: A theory for decades of C vulnerabilities
#9[flagged]
Stop resisting.
Re: A theory for decades of C vulnerabilities
#10I 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 tha…
This is one of the beauties of Clojure’s spec. You can define a ‘type’ that is a string which length is a prime number and contains only Ascii characters but ‘x’. To put those invariants in code and not in your head is so liberating.