>Linux actually doesn't bother fixing a lot of the kind of bugs I'm talking about (thus their use of e.g. -fno-delete-null-pointer-checks) and doesn't bother being portable between different compilers. >

Correction, thy don't bother fixing some of the bugs you are talking about. A lot of the other bugs that you are talking about (bugs due to the C language) are fixed. Your proposal was to not add any fixes due to bugs in the C language.

>> Oracle should also throw away their database code. As you say, it's faster to rewrite their 30m LoC database than to add a few lines of bugfixes.

>Oracle only stays alive because of aggressive sales and legal teams.

What does that have to do with your proposal? In fact, if as you say that Oracle is alive because of non-technical reasons, then your proposal that a rewrite is better than a bugfix is even more unreasonable - they can use their lock-in to spend a decade rewriting their core products.

They aren't doing this though.

> H2 is both more standards-compliant and better-performing (why do you think Oracle's license doesn't let you benchmark it?).

How is that relevant?

>> Wait, hang on ... what about my volvo s/wagen? The various ECUs in it are all written in C! Certainly I don't want them to fix problems and roll out a patch next week. I'll wait the 5 years it takes for them to rewrite the entire system.

>> Then, of course, there's airliners. You're completely correct that we should not fix the problems in their code; we can shutdown air travel for the 8 years or so it takes to rewrite the system.

>Safety-critical software is not written in C in the sense of everyday C codebases. It might be written using C syntax, but that code will not be treated as normal C: specific (often non-optimizing) compilers will be used, analysis tools will be applied, particular coding policies will be applied, using arbitrary C libraries is right out...

I've worked as C programmer in safety-critical software. Specifically, in munitions control. The "safety" that comes is not from religious adherence to MISRA-like guidelines but from regulatory bodies who specify the process around QA, testing and official release of the software.

Changing from C to another language might help, but rewriting the entire product is out the window completely - the regulatory hurdles to re-certify and re-test alone means that such an attempt is bound to kill the rewrite effort outright.

I'm currently working in another field (C and C++ this time), and making small incremental changes is considered by the regulatory bodies as less risky than throwing everything away and restarting.

The meme "scrap C, rewrite it in $FOO" only applies to software that has very little impact on the world.