Ricardo Mestre wrote: > I made an inspection on userland tree and there quite a few > applications still using strncpy(3) instead of strlcpy(3). Some of > them may never need that safety since the boundaries are always fixed, > nevertheless since strlcpy is a drop-in replacement it doesn't hurt to > use, plus it will always be safer than strncpy.
It does hurt a little bit, sadly, because the l variants are not POSIX-et-al-specified and many platforms don't have them. They're easy to add to a port's compat code, but many devs have a slight preference for the n variants in safe, fixed-bounds situations because of the porting headache. Also, as always, churn. Using these sorts of things everywhere also makes it a little harder for people to pull functions or chunks of code, although I don't know how much other devs care about that. That said, there are specific tools (I'm thinking of httpd and friends, and smtpd) that already have compat systems. In those, maybe more l variants wouldn't hurt. > The same question goes for strncat(3)->strlcat(3), can they just be > swapped without causing any hiccups? Or should it be kept as is? What > about kernel space? There's also some usage there. IIUC, the kernel is a good place for safer but unstandardized features. I'd be happy to review some of these.
