> The worst possible scenario for the safercopy() function is that you are given an erroneous length for one of the strings and that string does not have a '\0' properly, so the function buffer overflows.
Your argument is that the safercopy() function is "safer" in that it is guaranteed to terminate regardless of whether the underlying buffer has a NUL byte in it. While that's true, it's sort of missing the point a bit, I think. The unsafe copy() function wasn't primarily unsafe because there was no guarantee it would terminate -- it was unsafe because it corrupts a bunch of memory, exposing you to a wide range of insecurities (the least of which is that your program might crash). safercopy() is still prone to that behavior if the lengths you pass in aren't accurate. While it is guaranteed to only corrupt n bytes of memory rather than an arbitrarily large number of bytes, the damage might as well already be done by the time you corrupt those n bytes. So to answer your question:
> How do you think an alternative copy function that uses lengths would have buffer overflows?
It's unsafe in exactly the same way that the unsafe copy() function is: if the arguments you pass into the function are incorrect/don't point to the data you think they point to, you'll corrupt memory. Now, you could make the argument that it's much easier to just remember the lengths of all the buffers you allocate than it is to remember to NUL-terminate all your C strings -- I would agree -- but I don't know if the article does a great job of explaining that.
> It's unsafe in exactly the same way that the unsafe copy() function is
No, that's the logic error every programmer makes. The copy() function is always wrong, because it can't confirm that the string has the right length without looking at the string which causes the error.
With my function I can go to as great a length as I want to confirm that the string is actually as long as I say it is. I can't mitigate every possible error of misuse, but the errors safercopy() can have are much smaller than copy().
Your argument is effectively stating that because you can exploit one with a general "UB" error, that it's the same size and classification of errors as with the other. That's invalid, and proven in my writing.
If the lengths are wrong. You said that the function shouldn't assume that strings are null-terminated correctly -- why should it assume that the lengths are correct?
> The worst possible scenario for the safercopy() function is that you are given an erroneous length for one of the strings and that string does not have a '\0' properly, so the function buffer overflows.
Your argument is that the safercopy() function is "safer" in that it is guaranteed to terminate regardless of whether the underlying buffer has a NUL byte in it. While that's true, it's sort of missing the point a bit, I think. The unsafe copy() function wasn't primarily unsafe because there was no guarantee it would terminate -- it was unsafe because it corrupts a bunch of memory, exposing you to a wide range of insecurities (the least of which is that your program might crash). safercopy() is still prone to that behavior if the lengths you pass in aren't accurate. While it is guaranteed to only corrupt n bytes of memory rather than an arbitrarily large number of bytes, the damage might as well already be done by the time you corrupt those n bytes. So to answer your question:
> How do you think an alternative copy function that uses lengths would have buffer overflows?
It's unsafe in exactly the same way that the unsafe copy() function is: if the arguments you pass into the function are incorrect/don't point to the data you think they point to, you'll corrupt memory. Now, you could make the argument that it's much easier to just remember the lengths of all the buffers you allocate than it is to remember to NUL-terminate all your C strings -- I would agree -- but I don't know if the article does a great job of explaining that.