[pjmlp]

The problem is that with LLVM, GCC, CUDA, Vulkan, POSIX, V8 and co, there will be lots of new C and C++ getting written as well.

Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++.

There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to tame unsafety on our computing stacks.

[timhh]

There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want.

V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I assume they have some other sandboxing methods instead though.

But in general if you think about things like V8, that's used on high performance application class consumer CPUs. It's going to be at least 10 years before anyone has one of those with CHERI (unless ARM changes its mind about Morello). I would not bet against V8 being ported to Rust before that.

As I said I think CHERI is great technology and I hope it does succeed, but it does seem like the business case for it is not as strong as it was just a few years ago.

[pjmlp]

Why not? There are many cases where it matters, also routine CVEs show how well tested they are in practice.

[timhh]

Why not what? Sorry I'm not sure which bit of my comment you are responding to.