I didn't say there were no corruption issues. Just that they're rare and a very small minority of the time is spent chasing them.
In return, get determinism and optimality of execution.
I think in ~10 years of C development, I had seen maybe 1 corruption bug slip through the testing suites to production. The vast majority are caught in unit tests, system tests, or QA.
I think it took 2-3 days of a 2-3 devs, but that's mostly because any production bug was very very expensive (Need to be very careful not to damage production machines).
But the search for the corruption was usually a couple of hours, perhaps a day's project.
If you utilize tools like valgrind, poison data that is released to pools, follow strict coding conventions, heavily test-cover your code, and become gdb-savvy, corruption bugs become not that expensive.
> If you utilize tools like valgrind, poison data that is released to pools, follow strict coding conventions, heavily test-cover your code, and become gdb-savvy, corruption bugs become not that expensive.
Watch Herb Sutter's CppCon 2015 presentation.
Apparently among the top of C++ developers that managed a ticket to get there, only 1% of the audience uses such tools.
I didn't say there were no corruption issues. Just that they're rare and a very small minority of the time is spent chasing them. In return, get determinism and optimality of execution.