RPM Community Forums

Mailing List Message of <popt-devel>

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

From: Wayne Davison <wayned@samba.org>
Date: Sun 09 Mar 2008 - 06:26:25 CET
Message-ID: <20080309052624.GC22877@herod.dreamhost.com>
On Sat, Mar 08, 2008 at 10:42:36AM -0800, Wayne Davison wrote:
> (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

This is apparently no longer true.  The strdup_vprintf() function
expects to get a valid length back after calling with a limit length of
1, so this code is currently broken on systems that return -1 for
overflow, and there is a variable overflow of the "char c" stack
variable on systems that don't count the null in the limit.

So, it looks like you need to fix that before releasing 1.14.  The
variable overflow can be easily fixed by making c a 2-character array,
(or perhaps passing a 0 limit to snprintf() instead of 1).  Avoiding a
return of -1 could be fixed by substituting a working snprintf()
function, if you want to go to that extreme.  Rsync does this using this


For rsync, I just use asprintf() to get an allocated string from a
printf() format, and that has been quite portable in all the various
systems that rsync runs on (including various flavors of Unix, Linux,
and Cygwin).  I don't know if you ran into a compatibility problem that
made you want to avoid it, however.

Received on Sun Mar 9 06:26:29 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.