AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2010.07.08 16:25 "strlcpy vs strncpy", by Bob Friesenhahn
2010.07.08 18:03 "Re: strlcpy vs strncpy", by Lee Howard
2010.07.08 18:06 "Re: strlcpy vs strncpy", by Olivier Paquet
2010.07.11 17:36 "Re: strlcpy vs strncpy", by Edward Lam
2010.07.12 19:30 "strncpy in tiffcrop", by Richard Nolde
2010.07.12 20:31 "Re: strncpy in tiffcrop", by Edward Lam
2010.07.10 11:04 "Re: strlcpy vs strncpy", by Albert Cahalan
2010.07.10 13:27 "Re: strlcpy vs strncpy", by Kevin Myers
2010.07.10 13:50 "Re: strlcpy vs strncpy", by Bob Friesenhahn
2010.07.11 07:34 "Re: strlcpy vs strncpy", by Albert Cahalan
2010.07.11 08:06 "Re: strlcpy vs strncpy", by Toby Thain
2010.07.11 14:35 "Re: strlcpy vs strncpy", by Bob Friesenhahn
2010.07.10 13:39 "Re: strlcpy vs strncpy", by Bob Friesenhahn
2010.07.11 08:18 "Re: strlcpy vs strncpy", by Albert Cahalan
2010.07.11 16:35 "Re: strlcpy vs strncpy", by Bob Friesenhahn
2010.07.12 17:34 "Re: strlcpy vs strncpy", by Dmitry V Levin
2010.07.12 18:13 "Re: strlcpy vs strncpy", by Bob Friesenhahn

2010.07.10 13:50 "Re: strlcpy vs strncpy", by Bob Friesenhahn

On Sat, 10 Jul 2010, Kevin Myers wrote:
>
> I tend to agree regarding the use of standard implementations rather than 
> rolling your own whenever possible.  However, Bob F. is well versed in 
> portability issues because of his support for GraphicsMagick on multiple 
> platforms.  If he thinks there are enough compilers in widespread use that 
> don't support strlcpy to justify rolling his own, then he may be right.  Bob 
> is also a very good programmer, so I suspect that his implementation would be 
> quite good, and in any event it would be available for subsequent review, 
> verification, and correction/optimization if necessary.  But, couldn't this 
> kind of thing (roll-your-own vs. standard implmentation) be handled by 
> autoconf or something like that?

Thanks for the kind words.  My implementation has been in use for a 
number of years now, but only gets exercised in the case where the 
platform does not already offer strlcat/strlcpy.  It is not 
particulary optimized at all, but is written efficiently.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/