> The core principle of computer-science is that we need to live with legacy, not abandon it.
I feel like the author misunderstands what a "core principle" is. This here is (at most) a bitter lesson learned from several decades of experience. It's not a principle, it's at best a conclusion following multiple stories of getting rid of legacy systems, but even as that this is highly dubious.
I wouldn't even say it's the core principle of software engineering. It's not really a "principle" anyway: legacy is just a reality that we have to deal with.
And a perfectly valid way of dealing with it might be to throw it away and rewrite it. That's not a choice to be taken lightly, to be sure, but it's complete nonsense for the article author to suggest it isn't an option.
Microsoft has introduced SAL during Windows XP SP2 days, which these articles keep forgetting about, including that SAL is sadly largely ignored, other than Microsoft teams.
The author of this post seriously underestimates what is needed to get to memory safety. In particular, spacial safety is not memory safety - just adding bounds checking won’t get you there.
But yes, C can be memory safe. It’s just harder than the post makes it seem.
Sure, you can change C & C++ to be memory safe. You can either make the change mandatory which breaks backwards compatibility & may as well be a new language, make it opt-in which allows developers to forget & introduce errors (and doesn't fix any existing code), or make it opt-out which might help but only once people adopt the new version in 20 years (and still doesn't fix any existing code).
Also C & C++ are different languages. C++ is larger but accepts change more readily, C is much smaller but is much more resistant to change.
one pays orders of magnitude in overhead. It’s a band aid for parts of projects that can’t be written in higher level languages (most C and C++ things) or Rust (few C/C++ things are in this category).
This would if it could be applied to parameters and local variables would allow the expression of the same relation to the compiler as CHK_SIZE and
CHK_INOUT_SIZE though they would be annotations applied to pointers and arrays that refer to count variables rather than an annotation applied to the count variable.
This only handles a subset of bounds checks (spatial safety). It has nothing for temporal safety (UAFs), nothing for thread safety, nothing for uninitialized memory, and it doesn't fix C's defaults.
This is very much a "we have memory safety at home" situation.
Everything can be theoretically be safe if you just do X and Y, but very often the economical incentives are to avoid doing X and Y (mostly to reduce expenses) so if you don't have safety as a complete stopper (as in: program does not compile if you don't abide by safety) then programs will be unsafe until the end of time.
We have to stop the problem at the door, not let it in and try to pacify it after it has destroyed half the room.
What a nonsensical article. I mean yeah, guns with the safety off are perfectly safe if 100% of all users have perfect trigger discipline, right?
Slightly off-topic, I remember working with an apache library years ago, and I loved the idea of memory pools.
Basically, create a memory pool.
Then all memory operations such as malloc and free are associated with that memory pool.
When you were done, you could release the memory pool and everything, every allocation, would magically be cleaned up.
It probably makes more sense in the context of a web server request... the request gets a memory pool, all memory allocations/deallocations belong to it, and if there is some sort of error, everything is easily cleaned up.
Using compiler specific extenions isn’t really C, though. It isn’t portable and there is no specificed ABI. Add enough of them, and it might become a new language “C with Memory Safety”
Please, stop it.
C is not memory unsafe. It's the way you use it to be unsafe.
C is a kind of "high level assembly" language. And this is why it is used for a number of core things in the world, from OSes, to core libraries and tools.
It empowers programmers. At the cost of requiring careful programming.
It's like very sharp blades. Use them judiciously, and you'll get your job done fast and precise.
Forget about checking everything and you'll start bleeding.
The legacies of systems are a practical reality, not a "core principle" of computer science, that's the issue with the claim. Computer science barely even concerns itself with the limitations of real hardware, much less giving two shits about software legacies.
The conflating is no doubt coming from how many cs programs heavily comingle computer science with vocational training for becoming a programmer, but they're not the same thing.
Am I missing something, or is this post exclusively talking about bounds checking? Most memory corruption vulnerabilities are object lifecycle bugs at this point, aren't they?
Plato was walking by Diogenes the Cynic and saw him with GDB up on his screen, figuring out a memory error.
"If you would only code in Rust, you wouldn't have to fix those bugs." To which Diogenes replied: "If you would only fix those bugs, you wouldn't have to code in Rust."
I don't buy it. We have already learned empirically that "fix your bugs" (or, better, "don't write bugs in the guest place") is a failed solution to memory safety.
You could say the same thing about knives.[0] "Treat your tools with respect" is a failed solution to tool safety. From 1980-2008, knives caused almost 1,200 emergency room visits per day, entirely avoidable by using safety tools and PPE.[0]
Of course, this argument is silly. The absolute number of knives are used safely and without issue in the overwhelming majority of cases.
Yes, there are times when someone was sloppy and sliced open their hand, but that doesn't make vigilance a failed solution to tool safety. The accidents that occur with them are in the realm of tolerable risk.
C is fundamentally no different. The simplicity comes with footguns that frequently go off when used by people that don't treat them with respect and sometimes even when they are being treated with ample respect.
Although, now that I think of it, bicycles are probably a better metaphor. It's a simple, unshielded vehicle designed not for safety but for getting you where you need to go. Accordingly, riding a bike without crashing requires understanding numerous edge cases that if not respected will end with you grievously injured and sometimes even with respect you won't escape crashing. This is such a truism in cycling communities that they say as a mantra "It's not a matter of if you crash, but when."
You also have the subset of cyclists that ignore laws when using them and endanger themselves and others. Should we then ban bikes because precaution is a "failed solution" to prevent crashing and responsible use? Probably not.
The footguns with C and memory errors are super subtle though and cause random crashes. It would be more like riding a bicycle with thousands and thousands of potential errors and if you ever make the tiniest mistake in the repair and upkeep of it, it crashes in the middle of a ride.
The work safety world disagrees with that thinking. And several workers pay with very painful consequences when they override safety to make things easier.
And my advice for those who don't believe me is to go play and cut a tree with a chainsaw with a disabled kickback break and guards.
But we haven't proven that a type system is the place to track memory safety. Suppose we could have an automated memory safety bug report checker that isn't in the type system?
CHERI-RISC-V is being standardised [1], Codasip is working on a commercial implementation of CHERI-RISC-V [2], and lowRISC is working on the Sonata project [3] implementing CHERIoT.
The Early performance results from the prototype Morello microarchitecture report [4] predicts the overhead between 1.8% and 3.0%. We don’t know what that overhead would be in production until such a commercial implementation is delivered but we have enough evidence it is worth the effort with the current estimates and given that CHERI can deterministically prevent around 2/3 of memory-safety-related vulnerabilities [5], not to mention benefits of mitigating future unknown vulnerabilities with compartmentalisation.
This is abject nonsense to the extent that I hope it is machine generated.
Sufficiently carefully written C can execute without memory errors, in exactly the same way that sufficiently carefully written assembly can be. That's not a memory safe language, it's a program which manages to not corrupt its own state.
There are compiler flags, sanitisers, static analysis, testing strategies and so forth to help one write something in C that doesn't fall over unexpectedly, but even with absolutely all of it implemented you still don't have a memory safe platform to build on.
Yep. I'm so tired of articles like this. C is not a memory safe language. Full stop. "Don't write bugs" or "remember to use these arcane extensions and macros every single time" do not make C memory safe. Doesn't even make your code memory safe, because people aren't perfect and will make mistakes and forget things.
I think a better term would have been "non-breaking backwards compatible change". hard/soft forks are very much the jargon used when talking about ways to upgrade blockchain based protocols.
I feel like the author misunderstands what a "core principle" is. This here is (at most) a bitter lesson learned from several decades of experience. It's not a principle, it's at best a conclusion following multiple stories of getting rid of legacy systems, but even as that this is highly dubious.