Comment by yyyk
2 years ago
You're latching to one minor point and ignoring main points like 'According to POSIX we can't define strscpy's return value', and 'We are standardizing a widely used function while strscpy is used in exactly one place - and a strscpy which fixes the return value is used nowhere'.
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…
1 reply →