- 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 17:36 "Re: [Tiff] strlcpy vs strncpy", by Edward Lam
On Thu, July 8, 2010 14:06, Olivier Paquet wrote:
This seems to only affect tiffcrop and tiffsplit in a few places so maybe we could fix the code too? Some cases in tiffsplit appear useless anyway (strncpy in a buffer which was dynamically allocated to be large enough to contain the string).
I only see problematic uses of strncpy in tiffcrop. The other uses of strncpy (tiff2pdf, tiffsplit) use the common practice of explicitly NUL terminating the destination buffer immediately afterwards (ie. perform truncation).
I don't see any problems with switching to use of strlcpy() as a means to ensure safer (even if not ideal) behaviour. As long as this is a better than nothing solution. :)
Regards,
-Edward