This is another ancient (circa 1997) in POPT.
The argv returned through certain interfaces ('d have
to check, but the issue bites me every couple months)
has everything allocated in one contiguous blob so
that an experienced/lazy programmer just has to do
const char * s = "bing bang boom";
int ac = 0;
const char ** av = NULL;
int rc = poptParseArgvString(s, &ac, &av_;
....
if (av)
free(av);
i.e. no loop over that strings in the array is needed.
The issue is that there are corner cases that do
not conform to general expectations, where a string
can be reallocated, or otherwise manipulated freely
without considering whether the memory is part of
an argv array returned from POPT.
(As an experienced/lazy programmer I use this POPT (and RPM)
functionality a fair amount).
The problem is that in order to attempt "tuples" by parsing
a CSV attached to a single option like
--option bing,bang,boom
uniformly with POPT_ARG_ARGV (and I can think of several other
usage cases for "tuples"), how the memory was allocated
affects how "tuple" merges are implemented.
I'm likely to change the behavior in POPT 2.0 to allocate
all the strings independently to simplify "tuple" merging.
Which means that applications will have to explicitly write the
loop (and its trivial to add a helper function in POPT) to do
for (i = 0; i < ac; i++)
if (av[i]) free(av[i])
free(av);
But I can be convinced otherwise, and perhaps *shudder* arrange
for a "Have it your own way!" selector logic if I absolutely MUST
do that.
Personally I'd rather see KISS even if incompatible. It just
ain't that big a deal to write a loop where needed.
But -- as always -- this means I'm forced to debug everyone's
widdle valgrind exercises if/when POPT is abused and used incorrectly.
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
