Comment by saagarjha
2 years ago
I don’t actually care what it returns as long it’s something that doesn’t take O(n) to compute. Feel free to rename it too if you don’t want it to be confused with strscpy.
2 years ago
I don’t actually care what it returns as long it’s something that doesn’t take O(n) to compute. Feel free to rename it too if you don’t want it to be confused with strscpy.
A lot of what POSIX does is standardize current use. strlcpy was used just about everywhere in Unix - it's just that on Linux devs used a jury-rigged implementation because glibc.
There's a case for strlcpy standardization even when it's not the perfect function. A standard strlcpy will allow compilers to look at all the cases where the return value isn't checked and replace the strlcpy implementation with an as-if strlcpy implementation not requiring O(n) compute for return value - otherwise, the compiler needs to peek behind the curtain and see if the local jury-rigged strlcpy implementation (which may be called by a different name like g_strlcpy) matches the 'real' strlcpy, which it very likely does, but proving it is a different matter.*
Now, if we want to create the perfect string function, there's a case to do that separately. IMHO, strscpy isn't bad if we fix the return value issue.
* I'm assuming the build system will ensure projects use the 'standard' strlcpy where available, which I think is reasonable since they mostly already do that when it's not Linux.
I guess you are right and my actual annoyance is that people are using this function and I don’t think they should in many cases. I would’ve liked the function to mostly fade from use and not be standardized as a result…
Let this be a warning of what happens when the (g)libc folks refuse to consider programmer needs and offer no solution. Had glibc offered any semi-sane solution, they'd have won by marketshare alone and their solution would have been used everywhere instead. By the time Linus thought of strscpy, it was too late.
>'We want a semi-sane null-terminated string copy function'
>'All you need is memccpy, la-la-la'
>(Everybody runs away screaming, even the Linux kernel folks decides to create a string function)
>(OpenBSD has a ready solution and a decent enough reputation, almost nobody checks it)
>Versions of strlcpy are embedded everywhere.
>glibc is forced to implement strlcpy.