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