Or something. That analogy sounded better in my head than written down. The point is that IMO the blame lies squarely with the C language: it's a language that's used in a lot of complex parsing code and provides pretty much nothing to help with this, and if anything actually puts roadblocks in the way.
Are you aware that atoi("a"); is undefined behavior? It can crash, it can launch nethack, it can return 0.
If you outfitted a police force with guns without safeties and hair-pull triggers, and you have any sanity, you're not going to be surprised if the rate of accidental discharges goes up. Programmers use their programming languages a lot more frequently and with a lot less care.
So, sure, let's tell the programmers to be more careful. But the most careful of programmers know they'll still make mistakes, and seek out ways to aid themselves in catching those mistakes instead of hoping they can will them away. One such aid can be choosing another programming language that doesn't share C's language mechanics.
Put another way - programmer's mistake for choosing to use C's language mechanics. You could argue that's technically not saying it's the fault of C language mechanics, but I'd say that's splitting hairs at the best.
You could share the blame with a failure to properly fuzz, and insufficient use of static analysis. I'd be okay with that too.
so if you buy that car and you do that, it's your fault regardless of how poor the car design is
pretty sure trusting user provided data without validation is the programmers fault regardless of language
Excellent!
> it's in the manual
It's not in MSDN: https://msdn.microsoft.com/en-us/library/yd5xkb5c.aspx
It's not in the manpages: https://linux.die.net/man/3/atoi
Cppreference understates it has having an undefined return value, rather than undefined behavior outright: http://en.cppreference.com/w/cpp/string/byte/atoi
Tutorialspoint defines the behavior as returning 0, and fresh2refresh makes no mention of undefined behavior.
My eighth google hit for atoi finally, finally, gets it right: http://pubs.opengroup.org/onlinepubs/9699919799/functions/at...
If you buy or pirate a copy of e.g. the C89 standard, or refer to one of the free draft versions, it's of course properly documented there too. Neither shows up in the first 50 google results, naturally.
And, of course, by google result 9, we're back to square one - incorrectly defining the behavior as being "returning 0": https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi
FRONT
TOWARD ENEMY
So IMO it's absolutely pointless trying to argue with them in the first place. They are set in their ways and while a good chunk of them are pretty strict and excellent in what they do, they are not open to any changes.
I would be the first to agree that Go and Rust aren't ready to start replacing drivers but IMO people should start trying! (Or invest in LLVM some more?)
C/C++'s faults aren't ever going away. They're too convenient in their target area. I am against the overly-used "disruption" term -- I happen to believe the USA tech blogosphere bastardized the term long ago -- but IMO the systems programming area is very, VERY overdue for disruption.
It's time.