- 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.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
On Thu, Jul 08, 2010 at 11:25:26AM -0500, Bob Friesenhahn wrote:
GraphicsMagick is using strlcpy() and strlcat() for secure string copies. I will be happy to contribute versions that I wrote myself for use in libtiff if libtiff choses to rely on these more secure functions. Libtiff should name the replacement functions differently in order to avoid any possible conflict/confusion with system provided versions, or versions from some dependent library or program.
If these functions are going to be added to libtiff, please do not change their names. Instead, add an autoconf test and a couple of ifdefs so that on systems where strlcpy() and strlcat() are provided by libc no redundant implementations are added. Something like this:
configure.ac:
AC_CHECK_FUNCS(strlcat strlcpy)
Declaration:
#ifndef HAVE_STRLCPY
# define strlcpy tiff_strlcpy
[a declaration of strlcpy()]
#endif /* HAVE_STRLCPY */
Implementation:
#ifndef HAVE_STRLCPY
[an implementation of strlcpy()]
#endif /* HAVE_STRLCPY */
--
ldv