RPM Community Forums

Mailing List Message of <popt-devel>

Re: Any interest in eliminating sprintf(), strcpy(), and strcat()?

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 08 Mar 2008 - 21:22:53 CET
Message-Id: <DFA9A49A-4C47-4C5C-87AD-F9F06D969FEF@mac.com>

On Mar 8, 2008, at 1:42 PM, Wayne Davison wrote:

> In rsync I eliminated all use of sprintf(), strcpy(), and strcat(),
> replacing them with snprintf(), strlcpy(), and strlcat().  Would  
> you be
> interested in such changes if appropriate compatibility functions were
> defined?
>
> For instance, I could imagine a configure test to see if snprintf()
> returns a -1 on overflow, and a test to see if its limit is off by 1
> (some don't count the '\0').  Then, a simple wrapper function would
> handle both those conditions in a simple way (i.e. -1 could be mapped
> to the limit-value+1 without need to compute the real overflow length
> because popt doesn't ever call snprintf() expecting to find out how
> much bigger its buffer needs to be -- the limit would just be used to
> be extra sure that overflow was impossible.
>
> I have compatibility functions for strlcpy() and strlcat() that I  
> could
> snag from rsync.  These functions are better than strncpy() and  
> strncat()
> as their limit value is the size of the buffer (unlike strncat()), and
> the destination string will always be '\0'-terminated (unlike  
> strncpy()).
>
> I have most of the changes written for an earlier version (rsync  
> includes
> a version of 1.10.2 at present) that I could adapt for 1.14.
>

I can take a look, and am not averse to changing, but even snprintf  
has portability
problems wrto popt, and strlfoo is likely even more problematic.

There's *LOTS* of popt use around, so I tend to track with least- 
common-denominator
as much as possible.

73 de Jeff
Received on Sat Mar 8 21:22:58 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.