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
> changes what you checked-in to CVS. See if you agree with these
> 1. If the system has vasprintf(), just use that (avoiding issues 2
> & 3).
> 2. Always allocate one more byte than we need, just in case the
> 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
Off to tweak in vasprintf(3) ... I am happy to see sprintf start to
73 de Jeff
Received on Sun Mar 9 22:57:19 2008