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 


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 
> ----- End forwarded message -----
> Foreign references for this request are:
> -
> -
> Greetings,
>  Robert

POPT Library                                 
Developer Communication List             

Reply via email to