If the C language (not even a compiler, the language) somehow magically inserted bad code or rewrote your good code to be buggy on its own, you'd have a point.
Probably, because it's really bad.
Are you aware that atoi("a"); is undefined behavior? It can crash, it can launch nethack, it can return 0.
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
closer to a gun without a safety, which plenty of manufacturers sell
pretty sure trusting user provided data without validation is the programmers fault regardless of language
so if you buy that car and you do that, it's your fault regardless of how poor the car design is
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.