Where is the constituency that would want this "sensible C"? People who care about reasonable behaviour have already moved on to better languages, a la https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ... ; the people still using C are those who want "maximum performance" and don't think undefined behaviour is a problem, and so C compiler writers have (understandably) gone ever further in their exploitation of undefined behaviour to get that "maximum performance".
I don't think this can be reversed, and I don't think we should necessarily want to reverse it. We have better alternatives now. Let the C people do their thing, and get on with your life in a language that ensures that programs, even "incorrect" ones, have reasonable behaviour.
I'm pretty sure that a large part of the people working on legacy code bases would like to have a safer language. You don't move on to a better language if that means rewriting your whole project.
MTE is part of ARMv8.5, a hardware specification. There is no iOS device that ships with this–and I would expect very few (if any?) Android devices do as well. Do you have a source of it being a requirement for ARM-powered Android 11 devices? Because I would expect this to exclude almost every currently shipping device…
"Sensible C" would have to be a distinct language from C, at least as the latter is currently implemented, so it would still represent a change of languages for legacy codebases. It could probably interop with the C ABI, but we already have other languages that can do that; it's not at all clear that converting your codebase piecemeal to "sensible C" would be substantially easier than doing the same with, say, Rust.
It would also have source-level interop with C _APIs_, for which the only other language we have is C++, and which for that purpose has the same issues as C.
Cultishness is a spectrum, not a binary. C has always had a certain proportion of adherents who believed that "performance" (of code that implements microbenchmarks with unlimited hours of manual tuning) is the most important aspect of a general-purpose programming language, and that the problems of undefined behaviour are insignificant. I would say that both those viewpoints are crazy, but they are increasingly becoming the mainstream in the C community, via the mechanism described in the link: more moderate people are driven out, rendering the community more extreme, which then drives more of the moderate folk out, and so on.
I see something similar happening with functional programming. Beyond measurable improvements (ie, in error rate, etc) there is often a mindset where if a language does not implement the latest syntactic patterns, then the language cannot be considered truly functional. HN seems a breeding ground for these sentiments, and adherents can be quite self-righteous.
Out in the untamed wilds of the broader industry (and the further you move away from the Stanford sphere) I have found that fanaticism, of all sorts, tends to taper off, to be replaced mostly with the mundane tasks of churning out software for money.
Of course, no matter where you hail from, the influence of C is inescapable. Yet, provincial priests are mostly concerned with budgetary constraints and deadlines. If switching to Scala will make hiring 10% easier, then by all means.
One "fun" thing about working in Scala is that you get attacked from all sides; there are people who say that the language is too weird or too purist, and then there are people who say that the problem is that it makes it too easy to have mutable variables or imperative code, or the fact that it allows you to do traditional OO inheritance.
FWIW, my experience is that when you introduce a bit of mutable state or hidden side effects, you usually regret it later. I probably come across as fanatical at times, but that fanaticism is coming purely from painful experience; these academic, theoretical concerns become a lot less academic when you've had to deal with production bugs that they could have helped you avoid.
I find it impossible to imagine the same being true for the C devotees. I've seen fast and slow programs in all sorts of languages. I've never seen a performance problem in anything other than a scripting language that wasn't either solved with a little bit of profiling, or just fundamentally impossible in any language. I've seen a C++ program rewritten in Haskell for a 5x performance speedup. And I've seen so many segfaults.
FWIW, I've found it pretty easy to escape C. In JVM-land you really don't have to deal with it, at least 99.9% of the time; I've hit like two JVM bugs in my entire career. Scala is by no means the easiest to hire for, but it's a great language for getting on with solving business problems - whether you want to do that by churning out reams of code, or by abstracting out the mundane parts and writing only the parts that are specific to the problem. It makes the easy things easy and the hard things possible; very rarely have I felt that the language was limiting me or stopping me from doing what I wanted. There's plenty wrong with it, but it's the best choice I've found.
It is like the heresy of enabling bounds checking in C.
I have hardly seen a program where having bounds checking enabled was an issue, except naturally for stuff like real time audio or software 3D rendering back in the 16 bit days.
Even on 8 bit, plenty of successful software was written in Basic perfectly fine (naturally games were another matter).
The very few cases that it actually mattered, it sufficed disabling them locally on the hot loop that was actually relevant for it.
When using C++, enabling bounds checking on STL library types or making use of at() hardly caused me not to meet customer expectations.
I don't know anybody who thinks code performance is the most important aspect of "general purpose programming languages". Everybody I know who thinks C is good for performance recognizes it's for specific applications (OSs, graphics, realtime, finance, etc.).
Except nobody I know who uses C holds that view. I'm sure they exist, but without a unifying view there is no cult.
C is a well established and widely known language with many uses. It's certainly not right for everything.
Who is the one with extreme views here?
What are these "better languages" you speak of? Because I've been looking for a good C replacement but to no avail. C++, D, Nim, Go, Rust, Zig, Odin, etc; I've looked into them but none convinced me.
What were your issues with those languages? Several of them sound like reasonable options to me.
For a mature, general-purpose language my default suggestion is OCaml. If you really absolutely can't make garbage collection work for your case (something I've never seen happen to anyone who actually tried) then your choices are more limited (and I'd probably favour Rust, despite its relative immaturity).
There are any number of good languages out there, and I could happily go into the details of which I think offers the best combination of tradeoffs (Scala). But the bigger picture is that a memory-safe language with the ML featureset (in particular first-class functions, parametric polymorphism, type inference, and sum types) should be the minimum baseline these days, and represents a substantial step up from C (at the most basic and pervasive level, being able to do error handling with a result type vastly improves your defect rate). Within that category you have plenty of reasonable choices offering their own particular selling points.
For me: libraries not available or are just wrappers on a C library anyway, inflexible memory management, bad support for OS features, etc... A lot of it is just maturity. C is ancient.
People still programming in C want C, its why they're still doing it. But you can't claim there are "no better languages" when all you're really looking for is C.
You can also move to a static language of course. With C's mostly absent type system, Rust or Haskell might take some getting used to. But Go could be an easy transition, or Java.
The sort of optimizations that compilers abuse UB for aren't that useful, actually, and they don't actually require a compiler anyway; it's more about compiler writers overfitting for benchmarks.
I don't think this can be reversed, and I don't think we should necessarily want to reverse it. We have better alternatives now. Let the C people do their thing, and get on with your life in a language that ensures that programs, even "incorrect" ones, have reasonable behaviour.