4 ms·
The non-standard strlcpy can easily be replaced with the standard snprintf. Both can, and almost certainly should, be replaced by a library that takes care of m
by liw 13y ago
The non-standard strlcpy can easily be replaced with the standard snprintf. Both can, and almost certainly should, be replaced by a library that takes care of memory allocation for strings. Even a simple one will obliterate all of the problems that the usual style of C string handling has.
(http://blog.liw.fi/posts/strncpy/ http://blog.liw.fi/posts/strncpy/ is my rant about this. Others have made the point better, of course.)
- ef47d35620c1 13y agoI agree. C++ solved this problem many years ago. The solution is standard and safe to use everywhere on all platforms. std::string
- nly 13y agoExactly, and it's actually MORE efficient than raw C string handling. Even in C the solution is to give up and use a string handling library that will do a reallocation on append, not risk truncation.
- simias 13y agoThese days if you write C you probably want to be in control of your allocations (and avoid as many as possible). At least that's what I do. There are no excuses for not including strl* functions in all standard C libraries, it's just NIH that causes the status quo. strcpy and friends are broken because they are C string functions that can generate invalid C strings and fail the Principle of Least Astonishment. The strl* variants are safer, easier to debug (it's easier to catch a bogus truncation than a missing \0 that might still execute properly by chance on certain systems/builds but not others) and only requires a couple instructions on top of the existing string copy functions. I have yet to hear a reasonable argument about why they shouldn't be included (no, "horribly inefficient BSD crap" is not a reasonable argument).