| |||||||||||||
The ups and downs of strlcpy()The ups and downs of strlcpy()Posted Jul 20, 2012 4:18 UTC (Fri) by cmccabe (guest, #60281)In reply to: The ups and downs of strlcpy() by RobSeace Parent article: The ups and downs of strlcpy()
Yeah, the debate over strlcpy doesn't make a whole lot of sense.
Programmers who want to check for truncation will find it easier to do with strlcpy. It requires fewer lines of code. That makes it easier to audit the code and find bugs. Programmers who don't want to check for truncation aren't going to do so anyway, no matter what API you add or don't add to the standard library.
C is a fundamentally different language than most of the modern languages out there. It's not managed. There will always be a way for the programmer to screw up. People seem to not grasp this concept. They think strlcpy should not be added, because somewhere-- maybe hiding under the couch-- is a perfect function which will magically make copying strings in C safe, like in the managed languages. There isn't.
(Log in to post comments)
The ups and downs of strlcpy() Posted Jul 20, 2012 21:08 UTC (Fri) by smurf (subscriber, #17840) [Link]
Not to mention the fact that you don't need two passes through your string.
Look, we all know that there's no magic bullet in programming. Different tools do different parts of the job well, others … not so much.
Fortunately, there are two quite simple workarounds for not having strlcpy in libc:
* add -lbsd to your GCC command line.
* #define strlcpy(d,n,s) snprintf((d),(n),"%s",(s))
Which of these is more efficient is left as an exercise to the reader. :-P
|
|||||||||||||