I guess you don't spend too much time looking at the typical C code written on most average enterprise shops.
Back when I used to code C professionally on early 2000's, these type of issues were quite common.
Specially since regardless of what one reads on HN, or hears at most conferences, most of those companies, which tend to see IT as a cost center, usually don't employ any processes regarding code reviews, static analysis or unit tests.
Which in languages like C this means an heavy price when things blow up, or the way things are going with IoT.
So given the increase in CVE entries, this still matters a lot.
I think that this might be true in the early 2000's, I hope that we have moved on significantly by now. I know that the automotive folks are getting a lot better at code review, static analysis and unit testing.
Yeah, and keep in mind that the developers who even attend CppCon 2015 are probably in the top 10% (at least) in terms of interest in these types of things.
It might be that they're in the top 10% of interest in ramping up in these types of things. I'm sure I'm not alone in having little interest in attending a technical conference that mostly covers things I already know - I'm there either to learn, in which case I want new content - not rehashed content - or I'm there for other reasons. Low rates of already using these tools, then, may make a certain amount of sense. If they were already putting them to practice, they may be less likely to attend.
Or I could be way off base - I've never attended CppCon. And I do love me some ASAN when I need it ;)
Indeed. If you contrast it against other engineering disciplines, even a closely related one like hardware engineering or FPGA engineering, the mindset is totally different. The amount of checks, reviews and many other practices is astounding.
... which is even more surprising given that many of these practices (in software) are almost-free. Granted, there aren't compile-time guarantees for most of these things, but with ASAN/UBSAN/etc. you'll certainly find the top 90% of your problems pretty fast.
In my experience diligent programming and going to conferences (or giving talks at conferences) are inversely correlated. Many conference pundits do little to no actual programming in the first place.
I'm not sure exactly what you're driving at, but for conferences like CppCon (and similar), the driving factor is usually technical interest and not just a way to waste time away from work (while drinking every night or whatever[1]).
So... could you explain what you're insinuating so I could respond to that instead of just guessing?
[1] Not sure about CppCon, but all "technical" conferences I've personally been to did have a lot of late-night drinking, but that was secondary to the technical stuff.
I'm intimately familiar with an in-production, business-critical code base and there's not a single best-practice it doesn't breach. If the compiler, on it's most lenient setting, allows it, then it has been done. It's fortunately not in C, but it tries to compensate by being pretty big.
I'm non-native English speaker/writer too. The qualifiers and disclaimers that I'm objecting to are not grammatically wrong. The point I'm making is that your statement loses all force due to the style.
Back when I used to code C professionally on early 2000's, these type of issues were quite common.
Specially since regardless of what one reads on HN, or hears at most conferences, most of those companies, which tend to see IT as a cost center, usually don't employ any processes regarding code reviews, static analysis or unit tests.
Which in languages like C this means an heavy price when things blow up, or the way things are going with IoT.
So given the increase in CVE entries, this still matters a lot.