The problem cannot be documented for POPT_ARG_ARGV because the behavior is dependent on how POPT is built.
Traditionally (to minimize memory fragmentation), an ARGV array was allocated in one continuous memory chunk so that a single free released both the array and all the strings. Depending on how compiled, an ARGV array can now have separate allocations for the array and each string. Documenting a build dependent behavior hardly explains how popt was built. And the amount of memory being "leaked" (technically its not a leak but a one-time allocation that isn't free'd) is hardly consequential. There is similar twistiness with how strings through aliases are returned that is difficult to document. popt code has been tortured to maintain compatibility. A proper fix cannot be achieved without breaking ABI compatibility. hth 73 de Jeff On Nov 24, 2013, at 11:21 AM, Robert Scheck wrote: > Hello all, > > I am forwarding a message of Christoph Anton Mitterer (Cc'ed) which was > reported at Red Hat Bugzilla. However this does not feel for me like a > downstream thing but more relevant for popt upstream, thus relaying it: > > ----- Forwarded message ----- > Hi. > > Popt has the options to "automatically update program variables when the > option is used". > This is done by the argInfo and arg elements of option tables. > > > 1) For all the pointer types, i.e. POPT_ARG_STRING and POPT_ARG_ARGV it does > not document[0], > what kind of memory this is (I guess dynamically allocated) and whether the > user has to > free this (I guess so). > > This is especially missing in the section "1. THE OPTION TABLE". > > > 2) Again, for all the pointer types, i.e. POPT_ARG_STRING and POPT_ARG_ARGV > it does not > document, what happens to the memory previously pointed to by the arg > variable. > I guess(!) this is not freed (it could have been dynamically allocated), so > it should at > least be documented, that no special care is taken by popt. > > > Cheers, > Chris. > > [0] It does however document in section "3. PARSING THE COMMAND LINE", that > the string returned > by poptGetOptArg() has to be freed by the user. > I guess the same should be the case for the variables set via POPT_ARG_STRING > and POPT_ARG_ARGV. > ----- End forwarded message ----- > > Foreign references for this request are: > > - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666245 > - https://bugzilla.redhat.com/show_bug.cgi?id=811799 > > > Greetings, > Robert ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
