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 ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
