MTE is as much a detection tool as it is a relied on layer of defence. I read that it has a 15 out of 16 chance to catch an error. Which means even if you do find a bug, it's going to be logged back to the OS vendor essentially the first time you use it. Getting patched permanently in the source.

Memory coloring (what is to my knowledge being proposed) is certainly probabilistic however it really does a lot towards memory hardening more than memory safety. It makes successfully pulling off ROPs, etc far harder.

Even if you are using a memory safe language, memory bugs still pop up in various places (cough FFI & ABI cough) so this is a massive step in the right direction towards blocking attacks even when the developers have done "all the right things" short of formally verifying their stack from top to bottom (and even then).

I've been meaning to ask you what the motivation of your project is? Why would you want a safe-c? When I saw the headline I was worried that all my runtime code would break (or get slower) because I do some very unsafe things (I have a runtime that I compile with -nostdlib)

I'm also tempted to write a commercial C++ compiler, but it feels like a big ask, paying for a compiler sounds ridiculous even if it reduces your compile time by 50x