Portability Is Reliability

But those layers are not part of your own work, they are external tools. Yes, it would be great if one of those would just catch all the bugs, but that's not happening.

So you have to choose either one single slice of Swiss cheese, or you work a bit on your plate to be able to add additional safeguards.

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

Bug free is not achievable, in no language. But good enough, secure enough, functional enough are achievable goals.

For many existing code bases (especially for projects with clearly defined scope) good enough is easier achieved by fixing up C code compared to a rewite in a different language.

Was it a different language from the beginning it might have been cheaper overall, but at some point the rewrite will just consume more money to reach the same state.

What is meant by that? I understand it like: don't write platform-specifc hacks. These rely on assumptions about behavior definitions for in general non-defined behavior.

An example: sometimes you can read meaningful data from memory after a free() because no one overwrote it. On your platform in your situation this can work.

It is clear for everyone that this is a bad idea. It would be great to have a low cost tool that tells you about such a bug. One class of tools for this are sanitizers. The author proposes another additional class of tools: testing your program with a run on another platform.

And why this could lead to more simplicity in the source code? A use-after-free bug comes from too much complexity. The programmer couldn't keep all the complexity in his or her mind. I bet in general well-written solutions without platform-specific assumptions look more simple and are better to understand for a human.

Clearer code because of more found bugs because of an extra bug-finding tool (cross-platform testing).

I feel like this is because our standards for "good enough" are so low, partly because languages like C and C++ make it so hard to do any better. It's true that there is a high cost to switching languages for an existing project, but the cost we are paying for all of foundational tools and libraries being built in a shaky unsafe way is also huge.

Studies I've seen suggest that ~70% of security vulnerabilities in C and C++ codebases are bugs (memory safety, thread safety, undefined behaviour) that would be caught by static checks in other languages. Think how much time and effort goes into ensuring basic safety invariants in C codebases. Then think how many of the remaining logic bugs we could catch if that effort was spent entirely on finding them.

If it takes the form of #ifdef WIN32 directives then yes, you're increasing complexity in the name of portability, but if instead you're making an effort to avoid using platform-specific non-standard features, then that doesn't increase complexity, other than requiring developer discipline.

Why? The short answer is: there is no free lunch. There is no silver bullet.

C / C++ has huge pitfalls with its memory management. But it is also a well-designed programming language with a great balance between efficiency and comprehensibility (and all other features of a language).

Every design decision in a language is a trade-off. And the trade-offs in C / C++ are so well chosen that there was no easy improvement for decades. No low hanging fruit. A C programmer has to understand much more about memory management because there is no virtual machine / garbage collector / interpreter running which takes care of it. But for that you get efficiency that is not possible by design with the other approaches.

For me C / C++ made the best trade-off.

Until Rust came along. Rust wants to make the memory management 10% better than C++ with 0% loss in efficiency. That is huge. No one reached something similar in 40 years. I am sceptical because this is such an ambitious undertaking. If that really works in real life I will be impressed.