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 poptFreeCon
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 sug
>
> What? A bug - albeit not a very serious one - that's been there for ever is,
> therefore, not a bug?
>
That isn't what I said, in fact quite the opposite.
73 de Jeff
__
POPT Library
Jeff Johnson wrote:
On Jun 16, 2010, at 4:59 PM, Markdv wrote:
Jeff Johnson wrote:
I happen to have a valgrind trace on my screen that shows the issue
==25160== ==25160== 49 bytes in 1 blocks are still reachable in loss record 2
of 2
==25160==at 0x4005BDC: malloc (vg_replace_malloc.c:195)
On Jun 16, 2010, at 4:59 PM, Markdv wrote:
> Jeff Johnson wrote:
>> I happen to have a valgrind trace on my screen that shows the issue
>> ==25160== ==25160== 49 bytes in 1 blocks are still reachable in loss record
>> 2 of 2
>> ==25160==at 0x4005BDC: malloc (vg_replace_malloc.c:195)
>> ==251
Jeff Johnson wrote:
I happen to have a valgrind trace on my screen that shows the issue
==25160==
==25160== 49 bytes in 1 blocks are still reachable in loss record 2 of 2
==25160==at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25160==by 0x314D9A: poptGetNextOpt (popt.c:1203)
==25160=
On Jun 7, 2010, at 2:38 PM, Jeff Johnson wrote:
>
> AFAIK, all POPT args are either returned by value (like POPT_ARG_INT) or
> through malloc'd memory _ALWAYS_. The rules on table callbacks are different
> than the rules for the no-brainer, in-line loop based getopt(3) like
> processing.
>
> OT
On Jun 7, 2010, at 4:40 PM, Danny Sung wrote:
>
> On 6/7/2010 11:29 AM, Jeff Johnson wrote:
>>
>> On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
>>
>>> I agree. I have no problems with breaking binary&source compatibility
>>> especially if that change will make popt better/easier in the futur
On Jun 7, 2010, at 4:16 PM, Danny Sung wrote:
>
>
> On 6/7/2010 11:38 AM, Jeff Johnson wrote:
>>
>> On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
>>
>>> My personal choice in things I write is to expect the caller to strdup().
>>> But I understand the reentrancy issue here. (though why you
On 6/7/2010 11:29 AM, Jeff Johnson wrote:
On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
I agree. I have no problems with breaking binary&source compatibility especially if
that change will make popt better/easier in the future. But a change in name seems
necessary for app developers to mak
On 6/7/2010 11:38 AM, Jeff Johnson wrote:
On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
My personal choice in things I write is to expect the caller to strdup(). But
I understand the reentrancy issue here. (though why you'd be using popt in a
thread is beyond me at this time.. and it doe
On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
> My personal choice in things I write is to expect the caller to strdup().
> But I understand the reentrancy issue here. (though why you'd be using popt
> in a thread is beyond me at this time.. and it does have a poptContext handle
> anyway).
>
On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
> I agree. I have no problems with breaking binary&source compatibility
> especially if that change will make popt better/easier in the future. But a
> change in name seems necessary for app developers to make that choice. eg.
> what happens if y
My personal choice in things I write is to expect the caller to
strdup(). But I understand the reentrancy issue here. (though why
you'd be using popt in a thread is beyond me at this time.. and it does
have a poptContext handle anyway).
But yeah, I guess I'd opt for consistency as well. The
I agree. I have no problems with breaking binary&source compatibility
especially if that change will make popt better/easier in the future.
But a change in name seems necessary for app developers to make that
choice. eg. what happens if you're building mulitiple different
software packages...
On Jun 7, 2010, at 12:51 PM, Wayne Davison wrote:
> On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson wrote:
> The added tyrrany of forcing every application that currently has
> -lpopt
> to change to
> -ljdod
> will be rate-determining to adoption (and glacially/tectonically slow imho)
>
On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson wrote:
> The added tyrrany of forcing every application that currently has
> -lpopt
> to change to
> -ljdod
> will be rate-determining to adoption (and glacially/tectonically slow imho)
>
For me, if popt 2 is not compatible with popt 1 then I would ra
On Jun 7, 2010, at 12:20 PM, Wayne Davison wrote:
> On Mon, Jun 7, 2010 at 9:14 AM, Jeff Johnson wrote:
> And without some deterministic way to tell whether its a POPT 1.x <-> 2.x
> table being fed to the POPT API/ABI, well, only a deliberately
> "incompatible" POPT 2.0 data structure with some
On Mon, Jun 7, 2010 at 9:14 AM, Jeff Johnson wrote:
> And without some deterministic way to tell whether its a POPT 1.x <-> 2.x
> table being fed to the POPT API/ABI, well, only a deliberately
> "incompatible" POPT 2.0 data structure with some deterministic
> version identifier is possible.
>
On
On Jun 7, 2010, at 12:02 PM, Jeff Johnson wrote:
>
> Changing the soname or even (gasp!) using ELF symbol versioning
> is quite doable, all the necessary precursor elements have been in place
> for years.
>
I should point out the deep flaw using ELF symbol versioning ...
POPT tables are compil
On Jun 7, 2010, at 11:50 AM, Mark Hatle wrote:
> Jeff Johnson wrote:
>> 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 expectat
Jeff Johnson wrote:
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
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 A
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.
Either by adding const style prototypes/functions, or by using some mechanism to
change the behavior of all of the f
I happen to have a valgrind trace on my screen that shows the issue
==25160==
==25160== 49 bytes in 1 blocks are still reachable in loss record 2 of 2
==25160==at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25160==by 0x314D9A: poptGetNextOpt (popt.c:1203)
==25160==by 0x40697CD: rpmc
25 matches
Mail list logo
