The problem is that the examples and explanations don't justify the level of castigation. Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs. The example of a safercopy() still relies on the assumption that the pointers given to it are valid, and that assumption is just as impossible prove as the assumption that copy()'s input strings are valid. Safercopy() is still twice as safe as copy() and we ought to use it, but calling copy() "defective" is unfair unless you're willing to call the C language defective in general. And you can make that argument! I certainly like languages like Go that have pointers but no casting ints to pointers or pointer arithmetic, so the only remaining danger is pointers to memory that has been freed.
"Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs."
I agree with your argument, but I don't enjoy encouraging programmers to use strncpy and co... the reason is simple, I don't want to encourage programmers to stop thinking about their code. Not having to think about something is great, when laziness is acceptable (RAD, web development etc.) but not in the general case...
Most of the time, the programmer should be smart enough to not fall foul of the problems strncpy avoids. The argument against the copy function in "learn C the hard way" implies that the programmer doesn't understand the code, language, or platform particularly well...
Mine is a fundamentally flawed argument though... as much as I want to live in a world where people can write code properly, the truth is idiots will always be out there. Although, as such, I would rather my code did shoot them in the foot if they were stupid enough to load it up and point it that way before firing... :)
The knowledge is esoteric to what is being done. I know its convenient to believe so, but there are smart people that make mistakes. Misusing one of these methods isn't discouraged because its obvious, its discouraged because it fails in non-obvious ways. Ways that have probably cost humanity many man years of development time.
You're saying that the language should make the programmer's job harder, and that it's a mark of laziness to try to arrange things to make common mistakes less likely?
Human brain has very limited bandwidth. The more irrelevant bs it has to deal with, the less effective is in solving actual problems.
It's surprising that people otherwise living day and night dealing with bandwidth and capacity issues of software systems ignore their own limits on bandwidth and capacity and are willing to put up with random bs in the name of some macho industriousness.
