- 2010.07.08 18:03 "Re: [Tiff] strlcpy vs strncpy", by Lee Howard
-
2010.07.08 18:06 "Re: [Tiff] strlcpy vs strncpy", by Olivier Paquet
- 2010.07.11 17:36 "Re: [Tiff] strlcpy vs strncpy", by Edward Lam
-
2010.08.06 18:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Toby Thain
-
2010.08.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
- 2010.08.06 15:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
- 2010.08.06 15:37 "Re: [Tiff] tiff4 on 32-bit Windows", by Olivier Paquet
- 2010.08.07 06:34 "[Tiff] tiffcp crashes on planar to strip conversion for < 8 bit", by Andreas Kleinert
-
2010.08.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
- 2010.07.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
- 2010.07.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
- 2010.08.02 19:47 "Re: [Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
- 2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde
2010.07.11 14:35 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
and I think on recent Solaris.
Yes (checked Solaris 10 10/09).
It was added in Solaris 8 (released February 2000)
It has been rejected by the glibc maintainer.
The glibc maintainer is strongly opinionated and rejects many useful things. That is one reason why glibc became forked. :-)
A nice thing I find about strlcpy/strlcat is that on Windows, the Visual Studio compiler does not know about these functions and so it does not warn that they are insecure. Use of most stdio I/O and string functions causes security warnings (by default) with modern MSVC.
Albert Cahalan's comment about some strings being stored in a fixed size space with no assurance of null termination is a good one. This is common for strings stored in file formats. It would not be wise to replace string functions willy-nilly without proper understanding of how each string may be composed and used.
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/