On Dec 6, 2007, at 5:41 PM, Danny Sung wrote:
> Hi, the popt source code references firstname.lastname@example.org as the
> maintainer, but that bounced, so hopefully this is the right place
> to send this...
> Sorry if this is old news to people... I /just/ discovered a
> memory leak in my use of poptGetNextOpt(). It wasn't clear from
> the man page that the calling function must deallocate this memory,
> so I added it (patch enclosed).
> Is this the intended behavior? If so, it seems that poptGetNextOpt()
> should return "char *" instead of "const char *".
The malloc under poptGetNextOpt() was necessary to add the
gawd awful syntax to generalize rpm CLI options to use popt
aliases instead as in (there's lots of examples in rpmpopt)
rpm alias --rebuilddbapi --define '_dbapi_rebuild !#:+'
rpm alias --rebuilddbpath --define '_dbpath_rebuild !#:+'
Basically the malloc is needed to make a copy of the next argument
without breaking popt's ABI.
You're right "char *" instead of "const char *", which is a remnant
of ancient hysteria when argv contents were returned directly,
not with a malloc.
The reasons for not changing are same as before, to minimally
disrupt popt's API/ABI. These days the issues are less critical than
before. At one point there were 2 popt's in RedHat Linux, and it
was a random crap shoot which one was used, essentially
blocking any sort of rational fixing or developing for popt.
> I'm referencing popt as included in rpm-220.127.116.11 and the version of
> I'm using is 18.104.22.168-2.fc6
> However, I did just check popt-1.12 in the fc8 project and saw the
> same code, so I don't think it's changed in a while.
Yep, popt changes very little, as little as is humanly possible.
I'll put in the 2 changes you suggest, will likely be in popt-1.13
which is to be released Real Soon Now.
73 de Jeff
Received on Fri Dec 7 19:20:43 2007