4 ms·

Hundreds of thousands of LOCs. ~15 developers I didn't say there were no corruption issues. Just that they're rare and a very small minority of the time is spe

• pjmlp 10y ago
  Once I spent one week tracking down a memory corruption issue introduced by someone on the team and deployed into production. Got a very interesting week tracking down that issue, while getting regular customer calls when the problem would be sorted out. I surely don't miss it.
  • Peaker 10y ago
    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.
    • pjmlp 10y ago
      > 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.