C can be memory safe

> 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.

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.

https://learn.microsoft.com/en-us/cpp/code-quality/understan...

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.

It’s so simple! Just be perfect. And have all the people writing the libraries you depend on be perfect, too.

Linux is already starting to use the counted_by annotation however only applies to variable length array structure members.

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 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.

> The core principle of computer-science is that we need to live with legacy, not abandon it.

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.

Gosh some people are really, really desperate to continue with the whole C-is-still-perfectly-fine thing aren’t they?

I mean sure, feel free to continue writing it, nobody else cares, but let’s not pretend it doesn’t have rampant issues.

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.

See also Clang bounds safety, an implementation of a very similar concept:

https://clang.llvm.org/docs/BoundsSafety.html

C can be memory safe, you just need to not write memory bugs in it. These 18345 heuristics, compiler warnings and macros might help a little.

>The core principle of computer-science is that we need to live with legacy, not abandon it.

...wat

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."

C can be memory safe, we only need to turn these features on. Oh, by the way, these features don’t exist.

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.

The way they’re using hard-fork and soft-fork, is that based on the blockchain usage of the words? If so, that makes it hard for me to take seriously!