--- Dan Scott <[EMAIL PROTECTED]> wrote: > Would we be interested in migrating to safer functions like strlcpy > and strlcat in the future? This wouldn't affect the Evergreen code > much, but a quick grep over the OpenSRF code suggests that there is > enough usage that we could benefit from that. David Wheeler wrote > about strlcat / strlcpy in his Secure Programming for Linux HOWTO
I never heard of strlcat or strlcpy before, so I looked at the page you cited, along with several other sites. The idea is that strcpy and strcat are vulnerable to buffer overflows; strncpy and strncat are designed to be resistant to buffer overflows, but they are hard to use correctly, and are often used incorrectly. In addition, strncpy is needlessly inefficient because it fills the unused portion of the receiving buffer with nul bytes. strlcpy and strlcat are designed to be resistant to buffer overflows, but with a interfaces that are easier to use correctly. Since it doesn't pad with nul bytes, strlcpy is more efficient than strncpy. In addition, since strlcat returns the length of the resulting string, it can make it unnecessary to call strlen afterwards to get that information. Not everyone agrees with this approach. When Christoph Hellwig submitted a patch to add strlcpy and strlcat to glibc, Ulrich Drepper emphatically rejected it. See the thread at: http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html Drepper wasn't defending the use of strcpy etc. Rather he pointed out that a good programmer knows how big his buffers are, and how long his strings are, and can use memcpy to move them around. Kaz Kylheku made the additional point that strlcpy and strlcat will encourage sloppy programmers to ignore the truncation of strings, thus replacing one kind of problem with another. Personally I have seldom used strncat, and I don't like using strncpy for long buffers because of the nul-padding. I'm not prepared to take sides in the controversy, except to make two points: 1. There is no silver bullet. Correct string handling requires careful coding, no matter what library functions you use. 2. As long as Ulrich Drepper is the maintainer for glibc, we will not see strlcpy or strlcat available by default in most Linux distributions. They arose in BSD and mostly stayed there, though they also spread to Solaris (where they behave slightly differently). If Evergreen or OSRF uses them, we'll have to include them in the distribution in some form, or otherwise require them as some kind of add-on. That said, it's probably worthwhile to audit our string handling code, looking carefully for buffer overruns and other mishaps. How we fix it is less important than whether we fix it. Scott McKellar http:/home.swbell.net/mck9/ct/
