Re: POPT's API has designed in memory leaks. What to do?

2016-02-15 Thread Seonkon Choi
On Thu, Jun 17, 2010 at 10:09:37AM -0400, Jeff Johnson wrote:
> 
> On Jun 17, 2010, at 4:27 AM, Markdv wrote:
> 
> > 
> > I just don't see why you wouldn't want to "fix" this. Seems like all you'd 
> > have to do is add
> > 
> >con->os->nextArg = _free(con->os->nextArg);
> > 
> > to poptFreeContext(poptContext con) and be done with it.
> > 
> 
> There's a double free with your suggested "fix" if/when the application
> has also free'd the memory returned.
> 
> 73 de Jeff
> 

Sorry Jeff,
could you please show me an example of double-free against with that "fix" ?

For the poptGetOptArg(), you mentioned,
~snip~
1554 char * poptGetOptArg(poptContext con)
1555 {
1556 char * ret = NULL;
1557 if (con) {
1558 ret = con->os->nextArg;
1559 con->os->nextArg = NULL;
1560 }
1561 return ret;
1562 }
~snip~
So if someone called the poptGetOptArg(), _free(con->os->nextArg) of the 
poptResetContext() will do nothing.

I know, this thread is too old.
But it was talking about popt >= 1.16 and people still are using the popt-1.16.
So it is not too old to continue.
__
POPT Library   http://rpm5.org
Developer Communication List   popt-devel@rpm5.org


Re: POPT's API has designed in memory leaks. What to do?

2010-06-07 Thread Jeff Johnson

On Jun 7, 2010, at 10:37 AM, Mark Hatle wrote:

 The way I've usually addressed this is to either add an option to the library 
 that changes the default behavior from strdup to passing the address with the 
 expectation of const.
 

I'd rather _NOT_ go the Have it your own way! route in
a API/ABI becuase it adds yet another datum that needs to
be extracted from lusers doing POPT support.

 Either by adding const style prototypes/functions, or by using some mechanism 
 to change the behavior of all of the functions.
 

(aside)
Well I've gone multiple ways with the C borkage of const char **
vs char *const * in POPT and RPM. These days there's so much spewage
from GCC that I don't believe that compilers or language hints solve
any real world issue. But I can/will go to PROT_READ mandatory hardware
enforcement using mmap(2) if that is what is desired. Its easier
to implement the code than it is to discuss the various religion's
coding fetishism's Yet Agin. But I digress ...

Note that it _WAS_ GCC's writable strings that forced the malloc
into POPT in the first place, where POPT sometimes returned
strings from RO memory, and sometimes from argv, and the morons were confused.
Adding the strdup() to POPT was 1 less issue to worry about. Another digression 
...

 My biggest concern is the potential retrofit of existing apps that expect the 
 current behavior.. but I agree with many of the submitters.. popt really 
 should be sending const points and then the app needs to strdup.
 

And so legacy compatibility again again again. POPT 2.0 is a major change
with no compatibility implied or intended. Meanwhile I will strive to
make the change as painless as possible. But there are issues (aka deep hacks)
that have been in POPT for a decade that aren't the right thing to do. And even
though I've overloaded just about everything possible in the 7-tuple of a
POPT table item, there are these issues:

0) overloading with bit masks and long - void * punning is quite 
mysterious to most.

1) bits in certain fields are _ALREADY_ ambiguous for certain values, 
with
subtle conventional contextual tests of other entries needed while 
using POPT.

2) there's a need for Yet Another Pointer for callbacks with context 
(changing item #5
from int to long would suffice but is instantly incompatible so 
I'd rather do something
less mysterious).

Thanks for comments however. And ignore my scarcasm if it offends.

73 de Jeff
__
POPT Library   http://rpm5.org
Developer Communication List   popt-devel@rpm5.org