On Mar 9, 2008, at 5:38 PM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote:
Meanwhile, below is a rewrite of POPT_fprintf, essentially identical
to the "man vsnprintf" example. See what you think ...
Looks good. I did some tweaking based on this code. The attached
patch
changes what you checked-in to CVS. See if you agree with these
points:
1. If the system has vasprintf(), just use that (avoiding issues 2
& 3).
Agreed.
2. Always allocate one more byte than we need, just in case the
system's
vsprintf() has an off-by-one bug with the limit.
That's kinda nutty (but hurts nothing). I'd rather fix a known problem
rather than trying to anticipate all possibilities ...
3. Moved the va_start() and va_end() calls back in the loop because I
believe that the systems that needed a va_copy() in the old code
won't like the reuse of "ap" without it.
... afaik 3) is <varargs.h> vs <stdarg.h> implementation dependent
confusion with va_start() and va_end(). But hurts nothing at all ...
Bonus question: I didn't think older systems supported the idiom of
realloc(NULL, len) doing a malloc(). I didn't check to see if that
idiom is already used elsewhere in the popt code, though, so I just
left that alone.
... and my ultimate answer is:
Deranged and ancient uglix-like systems, with busted vsnpprintf
and other damage,
can certainly live with gud old fprintf(3) as popt _USED_ to do
without all this dain bread
conversion from UTF-* to the native locale using iconv &
vsnprintf & nl_langinfo & wide characters &
malloc'ing fprintf's & ....
None of this modern crapola existed on systems that had busted
v*printf() implementations, almost
all the problems disappear with
#define POPT_fprintf fprintf
(and some tweaks to test whether POPT_fprintf is defined). KISS is
always better ...
I tested both sides of the HAVE_VASPRINTF code and this seems good to
me.
Off to tweak in vasprintf(3) ... I am happy to see sprintf start to
vanish ...
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
