These are valid questions a lot of people new to Rust have, so:

1. Rust is "backward compatible" in the sense that Rust code can use C libraries and C code can use Rust libraries - both ways via CFFI [1]. Security gaurentees only apply to the Rust code.

2. We've tired static and dynamic analysis of C to find security bugs for decades, there has been a plethora of research and commercial tools in the space. None fix the problem like Rust does [2].

[1] https://michael-f-bryan.github.io/rust-ffi-guide/ [2] https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

Almost any language can call C functions and we don't call all languages backwards compatible with C when they can merely interoperate with it.

Objective-C and C++ are the only two languages which offer backwards compatibility. AFAIK it's complete in the case of the former and there are some limitations for the latter.

None fix the problem like Rust does, but it's worthwhile to examine why: typical companies and developers have an aversion to paying for tools and for anything which slows down development. That's why usually those tools and languages which are reasonably user-friendly are more successful. Ironically that's both an advantage and a problem for rust: it's nicer to use than some C tools, but still not user-friendly compared to alternatives like Go or Java and in some cases even C++.

There is Cyclone, Checked C, Deputy. Such "C-but-weird" languages have an "uncanny valley" problem:

• "C, but safer" on its own is not very enticing. With no other benefits, it's easy not to switch, and instead promise to try harder writing standard C safely, or settle for analysis tools or sandboxes.

• People who use C often have backwards compatibility constraints. Switching to another compiler and a dialect that isn't standard C is a tough sell. You can still find C programmers who think adopting C99 is too radical.

• Programming patterns commonly used in C (rich in pointer juggling, casts, and textual macros) are inherently risky, but if you try to replace them (e.g. with generics, iterators), it stops looking like C anyway.

So "safer C" is unattractive to people who are tied to C implementations or don't want to learn a new language.

But people who do want to learn a new language and use modern tooling, don't want all the unfixable legacy baggage of C.

Rust dodges these problems by not being a "weird C". It's a clean design, with enough features to be attractive on its own, and safety is just a cherry on top.

Cyclone was not fully realized though.

And there are languages that try to keep to C and add some minor safety improvements, eg my language C3 (subarrays/slices, contracts, all UB has runtime checks in debug builds and more)

Sounds like marketing to me. It will convince young, gullible CS students, but not software engineers.

I think maybe you're conflating what Rust's borrow checker does with the notion of "security." They're related in that the borrow checker does some stuff that makes it difficult to create certain bugs that can be security issues, but they're not the same.

But to answer the question, I suspect no, and if you did it would be basically re-engineering the borrow checker and forcing Rust semantics into C and C++.

I don't know if anyone has proven it, but my hunch is that borrow checking C is undecidable.

1. You could possibly get closer, but you'd lose a lot. Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features.

2. No. If C/C++ could be made safe* Rust would not exist.

* everyone agrees on this point, including the richest and largest software companies on the planet

> Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features

Such as?

Lifetimes and the borrow checker.

A linter can do that.

Nope.

Just because you lack the ability to imagine something like that it does not mean that it is impossible. Sadly this kind of sentiment seems to be way too common in tech.

This wouldn't be possible in a practical sense. One could imagine a static analyzer of some kind which infers all lifetimes, though that would likely quickly be unworkably slow on real codebases, since you need to infer programmer intent. Additionally c static analyzers intended to catch all memory errors/UB etc. have existed for decades, and no one uses them, b/c they don't work or have too many false positives. For example did you know that until C++20 allocating an int with malloc was UB in C++? Would you want to work in a language where the linter marked every other line as UB?

It is impossible given the spec and syntax of those languages, which is why Rust exists, to enable these features...

C lacks the information given to the compiler to do this. It can't be added without adding that to the language. So no linter can do this alone, without language changes.

You can use _Pragma/#pragma, regardless though, you can achieve a lot of what lifetimes can without any annotation.

Pragmas are extensions to C, not part of the C language standard. You can add things to C, but it then ceases to be standard C and becomes GNU C or MS Visual C or early C++ or something else. But not ISO Standard C.

And yes, just about anything non-lexical lifetimes can do you can do with static analysis. But the set of things you can do with Rust includes things that need explicit lifetime annotations, which C doesn't have.

If you think we could get this right in C (48 years old) and C++ (35 years old), don't you think we would have done it by now? :-)

No, people tend to be quick to create a new language in addition to lacking imagination and thinking that it is impossible to do in C.

Too quick to create a new language?! Rust was started in 2006 and announced in 2010. Its improvements are based on research done before and after C/C++ existed.

If you're the only person smart enough to solve the $64B problem so everyone can start writing safe and backwards compatible code in C/C++, please, go right ahead.

yes writing a mini-rust compiler in C is possible and you can write in the mini language. But the problem is: at what cost?

This has nothing to do with what I am talking about.

You certainly do not even need to make a new language. Just making a new C implementation that aborts on buffer overflows for example would be enough.

This is an intractable problem because checking for buffer overflows requires buffer bounds and C pointers lack buffer bounds. Rust solves this by "fat pointer", pointer that knows its size, but fat pointer can't be the same size as thin pointer hence it would be backward incompatible.

Your C implementations lacks "buffer bounds". C by itself doesn't. There is nothing stopping a C implementation tracking the size of the data that a pointer points to (and these implementations are not even hypothetical, they actually exist right now).

> hence it would be backward incompatible

Rust is backward incompatible with C. A C implementation with fat pointers would not be backward incompatible with C. Depending on how it was implemented it could be ABI-incompatible with older C implementations but this is not necessary either.

The problem fat pointer based implementations are massively slower. Rust aims to provide safety without massive performance penalties. If one wanted safety without performance they would just use java or similar.

> The problem fat pointer based implementations are massively slower

I am challenging that. I do not believe that a C implementation that uses fat pointers needs to be any slower than Rust.

> If one wanted safety without performance they would just use java or similar.

Or C with a safe implementation.

Yeah like, rust also uses fat pointers. They should be equivalent. The issue is pervasiveness not speed.