Thank you for a sensible post. I agree that the only real solution has to be some abstraction or alternate mode for memory access that prevents the problem outright. C and C++ not only make it possible, but extremely easy to trash memory.

The people claiming that the problem is programmers who are incompetent or stupid and believing that they are superhuman genius programmers who are somehow immune from errors are living under a delusion. You are not a beautiful and unique snowflake. We are all human and imperfect. I have seen many intelligent and competent programmers write incorrect code. I have personally written code with errors. We need to move beyond unproductive blame assigning mentalities to achieve real solutions or we will never be able to advance the state of software. Realistically, the prima donnas will continue on and other people will actually do something.

memcpy_s is not a step forward for numerous reasons already mentioned. strncpy provides functionality that strcpy does not, namely a bound on its region of effect. memcpy was already bounded and neither memcpy_s or strncpy can prevent bad parameters from causing memory corruption. Hardware support like the NX/ED bits to mark pages as not executable are a good advancement on the security front, but still do not prevent data corruption. Complete removal of memory access like many languages do solves the problem with a high performance cost. Emerging techniques like STM may be able to incorporate data safety while maintaining hardware efficiency.