Re: Any interest in eliminating sprintf(), strcpy(), and strcat()?
On Mar 9, 2008, at 12:26 AM, Wayne Davison wrote:
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
code:
http://rsync.samba.org/ftp/unpacked/rsync/lib/snprintf.c
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.
Nah, I'm way not happy with the complexity introduced by undertaking
UTF-8 conversion on the fly in popt --help.
The va_copy boogered the popt-1.11 release, and the crapola _STILL_
isn't correct
or functional 3 releases later.
Meanwhile, what do you think of this patch:
Index: poptint.c
===
RCS file: /v/rpm/cvs/popt/poptint.c,v
retrieving revision 1.16
diff -u -b -B -w -p -r1.16 poptint.c
--- poptint.c 17 Feb 2008 00:53:49 - 1.16
+++ poptint.c 9 Mar 2008 06:13:42 -
@@ -129,7 +129,7 @@ strdup_vprintf (const char *format, va_l
/[EMAIL PROTECTED] ap @*/
{
char *buffer;
-char c;
+char c[2];
va_list apc;
int xx;
@@ -137,7 +137,7 @@ strdup_vprintf (const char *format, va_l
va_copy(apc, ap); /* XXX linux amd64/ppc needs a copy. */
/[EMAIL PROTECTED] =unrecog @*/
-buffer = calloc(sizeof(*buffer), (size_t)vsnprintf (&c, (size_t)
1, format, ap) + 1);
+buffer = calloc(sizeof(*buffer), (size_t)vsnprintf (&c[0],
(size_t)1, format, ap) + 2);
if (buffer != NULL)
xx = vsprintf(buffer, format, apc);
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: Any interest in eliminating sprintf(), strcpy(), and strcat()?
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 code: http://rsync.samba.org/ftp/unpacked/rsync/lib/snprintf.c 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. ..wayne.. __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: Any interest in eliminating sprintf(), strcpy(), and strcat()?
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 __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Any interest in eliminating sprintf(), strcpy(), and strcat()?
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. ..wayne.. __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
