IO: fix an off-by-one bug

[apocelipes]

It's my bad, I didn't notice that ffStrCopyN will do strnlen(src, nDst - 1). I won't change ffStrCopyN because it has been used at many places and "-1" may be correct, so I only changed my code.

Fix that and add a comment to ffStrCopyN.

[CarterLi]

Did you test your change?

[apocelipes]

Did you test your change?

Tested, including address-sanitizer.

[CarterLi]

I mean, did you test your change before making your previous PR?

[apocelipes]

I mean, did you test your change before making your previous PR?

Before I use ffStrCopyN, I did all the tests. I think CopyN will do the same thing so I only checked the compiling result. This is my bad.

[apocelipes]

Although it sounds like an excuse, many similar functions do copy N bytes completely, so I had some preconceived prejudices, which led to the off-by-one bug.

[CarterLi]

You are right. The function name ffStrCopyN is kind of misleading. The number param N is expected to be the size of target buffer. N-1 is for storing the trailing \0. It's different from strncpy which copies N chars but may not zero-terminates the target string.

However, you should always test your code. This is not the first or second time introducing bugs by optimising code that is NOT the bottleneck. I don't think I want to merge these changes any more.

[apocelipes]

However, you should always test your code.

OK, I will. And sorry for introducing this bug.

[apocelipes]

I don't think I want to merge these changes any more.

Yes, that's your right, but it can not resolve all the problems. Add test cases to the test set is a better idea.

[apocelipes]

I don't think I want to merge these changes any more.

Also, I donnot want to say these words because it could make you mad, but I still need to say it: Everyone can make a mess, all of us, no exceptions. For example: 1487c91. See the commit history there are many mistakes made by me, you and others.
So no one is perfect, why not try to be peaceful and be kind to each other. We can work togther and make things be better.

I am also an impatient person, so I will never say that a second time. Try to work with others, I think that's why you add the Code of conduct.

Of course, it's your repo so everything is your call. I'm here to apologize if these words upset you, but my opinion won't change.

[CarterLi]

Everyone can make a mess, all of us, no exceptions.

Correct. You are always welcome to submit PRs that really resolve some issues or implement some features. PRs like #1382 don't improve anything (including performance), but increase code complexity and introduce bugs. I don't like them.

Don't get me wrong, I like performance improvements, and I'm accepting changes to improve performance at the cost of code complexity, but ONLY in common code.

#636 (comment)