[lelanthran]

> For the same reason, I don't find the argument for fixing bugs in C codebases at all compelling (at least if we're talking about "micro" bugs rather than overall architecture issues that might carry over to a future rewrite). Sure, there's a lot of C out there. Sure, a lot of the bugs in that C code are findable. But so what? However many bugs you uncover, you're unlikely to find them all, and even if you did then how would you know? So isn't fixing bugs in existing C codebases just throwing good money after bad? You know you're inevitably going to have to rewrite it all eventually anyway.

You're completely correct! The Linux kernel maintainers should stop bugfixing. It will be faster to rewrite it in a safer language than to add a one-line bugfix :-/

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.

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.

Gee, I wonder why everyone isn't as far-sighted and enlightened as you are.

[lmm]

> You're completely correct! The Linux kernel maintainers should stop bugfixing. It will be faster to rewrite it in a safer language than to add a one-line bugfix :-/

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.

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

> 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...

[lelanthran]

>> You're completely correct! The Linux kernel maintainers should stop bugfixing. It will be faster to rewrite it in a safer language than to add a one-line bugfix :-/

>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.

[lmm]

> 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.

They don't bother fixing large categories of C bugs, to the extent that Linux can't really be said to be a C program - rather it's a program written in an ad-hoc GCC-specific dialect. Not fixing bugs due to the C language (or rather, things that would be bugs if it was interpreted as a C program) is very much part of that.

> What does that have to do with your proposal?

I thought you were holding up Oracle as some paragon of technical excellence to be emulated, which it isn't.

> 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.

I don't know what you're suggesting or advocating here. I'm not a businessperson and don't have any idea what's the most effective way for Oracle to make money. I do know from personal experience that if you want to make a good product, switching from Oracle to something written in a safer language can help.

> 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.

Regulations are, sadly, often a long way behind what's actually effective.

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

On the contrary, the kind of software that actually changes the world tends to be written in non-C. Where C tends to be used is in the kind of software that's a marginal replacement for non-software.