RPM Community Forums

Mailing List Message of <popt-devel>

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

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 07 Jun 2010 - 19:41:16 CEST
Message-id: <86905ED9-203A-4B61-95BD-C71AC054246C@mac.com>

On Jun 7, 2010, at 12:51 PM, Wayne Davison wrote:

> On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson <n3npq@mac.com> 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 rather have to make a conscious choice to upgrade my code (testing it for compatibility), and having to change the libray name as a part of that is pretty minor.  Having a possibility for my program to be run-time linked with a library that is not compatible with what it expects would be very bad, imo.
> 

Last I checked you already had made your choice and included your own
private version of -lpopt (and the reasons are perfectly understood and have
nothing to do with POPT 2.0).

Your decision paths are all status quo ante no matter what is done (or not) in POPT 2.0.

And I point out that your decision paths are all independent of whether POPT 2.0 is
"compatible" or "renamed" or ... anything else.

Yes, your comments are valued, you send patches ;-)


Meanwhile the discussion on <popt-devel@rpm5.org> is intended to
explictly extract what problems/features need to be solved in POPT 2.0
before doing any coding.

(aside)
I almost added a RPN calculator to popt-1.16 this weekend past.
The implementation would have involved a table entry like

    int counter = 0;

  { "autoincrement", '\0', POPT_ARG_INT|POPT_ARGFLAG_RPN,       &counter, 0,
        N_("Demonstrate autoincrmenting using a RPN calculator"), "1 +"  },

where a simple uint64_t stack would push the existing value (with coercion), parse simple
digit strings onto the uint64_t stack, with the usual toy calculator arithmetic
operations of + - * / % & | ... , and then transferring the result (again with coercion)
back to the counter variable.

The exercise of in-fix -> reverse polish is left to inquiring minds. Hint: see wikipedia.

Alas I got (and am) side-tracked with RSA/DSA/Elgamal/ECDSA generate & sign methods
for RPM, so I did not get around to the RPN calculator and your "autoincrement" request.


73 de Jeff
Received on Mon Jun 7 19:41:43 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.