3 ms·

$ ./a.out kjv.txt Hmm... Why is this taking so long? ^\ $ db core ... a.c:28:strlcpy(dst, src, 8); ... > d src 0040000: 496e 2074 6865 2062 6567

• jandrese 11y ago
  That doesn't explain anything. The manpage explains the problem though: RETURN VALUES The strlcpy() and strlcat() functions return the total length of the string they tried to create. For strlcpy() that means the length of src. For strlcat() that means the initial length of dst plus the length of src. While this may seem somewhat confusing, it was done to make trunca- tion detection simple. So strlcpy/strlcat parse all of src regardless of what you pass on that third parameter. And they'll happily run off the end of the buffer if your string isn't null terminated. I see what Linus was so mad about now. All because they want to return the length of the original string instead of the length of the copied string. The underlying problem is that C is too limited in return types from functions. There should really be a fourth (optional) flag to strncpy that is set if the string was truncated to fit in the new buffer, and the function would return the number of characters copied, not the number of characters in the source string.
  • mzs 11y ago
    True, but another problem for kernel is when something takes too long, which is what I was highlighting in a light hearted manner. The different return is more like what MS does with the _s routines, though it uses a special length return and flag option.