Torsten Bögershausen <tbo...@web.de> writes: >>> strcpy() maybe? >> >> It was originally strcpy, then I wanted to get fancy and show Win3.1, >> Win95... but it got complicated (couldn't just do it based on the last >> bit of 'v'). Will revert. >> > Why not use strlcpy() ? > (This feels little like an overkill, but on the other hand it is safe to use > regardless > how long the buf is, and it is a good example how to avoid "overrunning" code)
I actually think such a blind belief in strlcpy() is a disease. Surely it will help you avoid overwriting other unrelated data after the string buffer you are writing into, but it does not help you very much to make sure what you wanted to place in the string buffer all got recorded in that buffer, unless you remember to check its return value to make sure it did not get truncated. Otherwise, you may be valuing other people's data, but you are not valuing your own data sufficiently enough. And if you (1) know how big your own buffer is, and (2) are checking if your call to strlcpy() copied everything you wanted to copy, it would not be more work to do it without strlcpy()---you need to know how big a string you are copying into anyway if you care about your own data to the same degree you care about other people's data ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
