> 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.
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.
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.
Deleted Comment
https://learn.microsoft.com/en-us/cpp/code-quality/understan...
But yes, C can be memory safe. It’s just harder than the post makes it seem.
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.
https://m.youtube.com/watch?v=JRoX9_lXJFg
https://news.ycombinator.com/item?id=40732745 https://embeddedor.com/blog/2024/06/18/how-to-use-the-new-co...
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 is very much a "we have memory safety at home" situation.
Say what? The -singular- core principle? Of computer science? I've never seen this principle written down in any computer science book.
Compatibility is something that users -and therefore vendors- care a great deal about, but don't confuse that with computer science.
At any rate C is inherently unsafe for a lot of reasons that cannot be made to go away.