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 - 20:38:00 CEST
Message-id: <84112D54-EF62-47F3-B6DA-61BCDD1140C7@mac.com>

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).

popt does not use threads, applications do. so its applications, not popt,
that force -lpopt into multi-threaded environments. All that POPT can
do is to try and work transparently in both environments.

> But yeah, I guess I'd opt for consistency as well.  The thing that surprised me was that while poptGetOptArg() expects the caller to free it, it's still returning a const.  I use 'const' not as memory protection (we know it doesn't do that), but as a signifier that the caller doesn't need to worry about freeing the contents.  But whatever, I just put a /* popt requires this to be freed */ comment every time I use it.

Yes. I've added const's wherever possible and necessary in popt.
Which is why I already know (from 10+ years of experience) that only
PROT_READ segfaults will communicate to developers that its _NOT_
a POPT bug.

> If this is going to continue to be the behavior, I'd suggest a poptFreeOptArg() call just to highlight the necessity (and deal with type and NULL pointer checks).

Why add a new method for what is already a well known operation called free(3)?

I mean I can add poptFreeArg in 1 #define to popt.h, but why bother?

> If all Get's in popt allocate, that's fine (I actually hadn't noticed that because I wasn't really expecting it).  But if there's ever a time when you have a mix, I'd also suggest function names containing "New" (or "Dup" or "Alloc" or something of the sort) to drive home the point that something's being allocated.  "Get" to me typically means retrieve, not allocate.  But like I said, it's not a huge issue.  Just add the poptFreeOptArg() and I think it'll be clear for everyone.

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.

OTOH, some of the code paths in POPT are quite twisty, perhaps there's someplace
where another strdup/malloc is needed.

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