Comment by yyyk
2 years ago
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.