Not mentioned in the article: macros, which surely are the traditional way to work with this in C and C++.
A theory for decades of C vulnerabilities
21–24 of 24 posts
Re: A theory for decades of C vulnerabilities
#22Re: A theory for decades of C vulnerabilities
#23I 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.
Don't know anything about clojure, but isnt this true with any language or library that implements schema validation? I'm thinking zod, for instance. Does clojure make it trivial?
Re: A theory for decades of C vulnerabilities
#24Earlier quoted context omitted.
Well, sure they make reference. Borrow checkers and memory ownership concepts, like in Rust, are pretty good at giving a very low overhead improvement over bare C pointers. But they're not as flexible. Shared memory complicates ownership rules. And invariably, any Rust program that involves real hardware will require dropping down into unsafe at some points. A safer program with an unsafe kernel is an improvement, do…
I don’t think you have to reach for something as invasive as a borrow checker to handle most of these conditions. Bounds checks, for example, are rarely skipped intentionally in the vast majority of C programs; rather, they’re just skipped accidentally or performed incorrectly. Combine that with the extremely common and well-known compiler optimizations for BCE present in many compiled languages, and I don’t think C…
Well said. I get the sense that C is kind of ossified today, and that the whole point is its compatibility benefit. I wonder what even makes it into the next C standard? I think c99 was the last meaningful one. Everything else is offloaded to the compilers, God bless them. -Weverything