LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2010
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2010.07.10 13:39 "Re: strlcpy vs strncpy", by Bob Friesenhahn
On Sat, 10 Jul 2010, Albert Cahalan wrote: > > That isn't a design flaw. You could argue that strncpy is > a badly chosen name perhaps. The intended use is for > character arrays, such as the one in wtmp and utmp files, > which are not really strings in the normal C sense. Note > how strncpy also zero-fills the remainder of the array; this > behavior only makes sense for the intended purpose. Right. The intention in libtiff and tools is usually to prevent a buffer over-run. But the need to assure null termination makes strncpy() almost as error prone as strcpy(). > So strncpy isn't intended to do what you likely want, but strlcpy > really does have a design flaw. It truncates the string. This > can cause a security problem. To deal with that you'd need > to check length and compare... but if you're going to do that > then you've already written as much code as you'd need to > write for doing things the standard and portable way: memcpy. > Yep, that's right, memcpy is in <string.h> for a reason. I tend to agree except for the fact that strlcpy() does absolutely assure null termination, even if the programmer made an error. Of course it does not protect against the programmer providing less allocated memory than claimed. >> GraphicsMagick is using strlcpy() and strlcat() for secure string >> copies. I will be happy to contribute versions that I wrote myself > > Many decent programmers have botched reimplementations > of various str* and mem* functions. You might need two hands > to count the number of tries it took to get strncpy right in the > Linux kernel. Sun shipped a libc that got these functions wrong > when crossing a page boundry. Well-optimized code often has > failures with bytes 0x7f, 0x80, and/or 0xff. You are saying that my implementations are flawed? :-) > You can expect a modern compiler and C library to cooperate > to provide a regression-tested implementation of str* and mem* > functions that takes full advantage of the hardware. (aware of > cache lines, aliasing issues, special-purpose instructions, etc.) > I strongly suggest using what the platform provides rather than > writing your own. String copy performance is usually not very important to libtiff performance. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/