Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Poettering: The Biggest Myths
Posted Jan 27, 2013 13:00 UTC (Sun) by ovitters (subscriber, #27950)
Posted Jan 27, 2013 16:40 UTC (Sun) by smurf (subscriber, #17840)
Anyway, nothing prevents them from implementing what's missing on their side.
In related news, *bsd came up with strlcpy(). Do we go to them and complain that it's non-standard? No, we go to our libc maintainer and complain that he doesn't want to include that in the standard library.
I see a fundamental asymmetry here. Which might just be part of the reason there are >=3 BSDs out there, but just one single Linux. :-P
Posted Jan 28, 2013 1:05 UTC (Mon) by mezcalero (subscriber, #45103)
The thing is simply that strlcpy() leads people to use fixed size arrays to store possibly much longer data in it, so they want the truncation. But if you do this, then you tend to hide a problem with it, and instead you should have the checked the length of the argument in the first place and returned an error (after all the general rule is to always check your input!). Implicit truncation without error condition is almost never a good idea. And if you didn't check explicitly for the overly long string, then you should handle that string in its entirety properly, which generally means dynamically allocated memory of the correct size, which still not requires strlcpy().
I do see a valid usecase for some ways to call strncpy() (to fill in fixed size strings in structs where you usually want to zero out the rest of the string), and there's a very useful usecase for strdup() -- but strlcpy(), not so sure.
But, then again, given how trivial the call is, and how many people want it, if I was glibc hacker I'd still merge it... This shouldn't be fought with the fervour that people fight it with.
Posted Jan 28, 2013 10:50 UTC (Mon) by smurf (subscriber, #17840)
Anyway, strlcpy was intended to be an example of the different styles of handling NIH situations in Linux vs. *BSD land. I didn't exactly intend to trigger yet another strlcpy sub-discussion. ;-)
Posted Jan 28, 2013 15:59 UTC (Mon) by epa (subscriber, #39769)
Posted Jan 28, 2013 19:42 UTC (Mon) by k8to (subscriber, #15413)
Sometimes I work on code that is assembling various things into buffers in order to generate a representation out-of-program, like on disk or on the wire. These things often work with fixed sized buffers into which they are assembling data, because the data representation has a fixed size.
In this case, changing codepaths to use strlcopy gives SIGNIFICANT improvements in safety. strncpy is not acceptable in these cases because it will incur large performance penalties with the null padding. Yes, we try to have sane and well placed logic to enforce the sizing, but putting the logic in each callsite is just begging for overruns which can be unacceptable in some use cases, so strlcpy gives us some safeguard, despite being careful in the logic.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds