[lmm]

> It is not specific to C/C++ - in any language there will be some bugs you're unlikely to find (before they are reported).

Perhaps (though frankly I doubt it). But at the very least it's very possible to avoid the "everything is a security bug by default" phenomenon of C/C++ undefined behaviour; your program may still crash occasionally, but a clean crash is relatively benign compared to security bugs or even just silent data corruption.

> If it took many years to write a big C codebase, then a rewrite likely will take significant time too (or you'll drop many useful features and/or introduce new bugs). And most software project take more time than anticipated, rewrites is not an exception here. Isn't is a waste of money too, just another kind?

If a rewrite is necessary, then the sooner you start the sooner you'll finish. I'm coming from a view that a) C/C++ code is always insecure and cannot be made secure b) as exploitation improves along with everything else, running insecure code will become increasingly untenable. You could disagree with either premise.

[afarrell]

> If a rewrite is necessary, then the sooner you start the sooner you'll finish.

A 8-person team might easily rely on more C/C++ code than could be rewritten by them in 3 years. This jumps to 10-40 years if you include external Open Source codebases like Nginx.

So, the team needs to prioritize and to do things in steps. While they are rewriting some C/C++ code, they'll need to still maintain other code.

...and they need to solve enough business problems to keep the lights on.

[lmm]

> So, the team needs to prioritize and to do things in steps. While they are rewriting some C/C++ code, they'll need to still maintain other code.

Sure. But I don't think kind of portability-for-reliability work described in the article is effective work that should be prioritised. Yes, it will catch some bugs, but there's not actually much value in that.