On Nov 24, 2013, at 11:57 AM, Robert Scheck wrote:

> Hello Jeff,
> On Sun, 24 Nov 2013, Jeffrey Johnson wrote:
>> AFAICT, the spell corrections here @rpm5.org
>>    - devzero2000: fix misspelling
>>      Fix misspelling using  http://github.com/lyda/misspell-check
>> are now being returned as a patch from Fedora.
> whoops...you are partially right. I should have checked that. Attached is a
> new patch for the two changes that did not yet happen upstream.

Hmmm ... what is checked into cvs is already fixed (so likely fixed since 
.RB "arguments. When " --usage " or " --help " are passed to programs which
use popt's automatic help, popt displays the appropriate message on
stderr as soon as it finds the option, and exits the program with a
return code of 0. If you want to use popt's automatic help generation in
A conversion from a string to a number (int or long) failed due
to the string containing non-numeric characters. This occurs when
.BR poptGetNextOpt() " is processing an argument of type "

>> I'm glad to hear that Fedora has upgraded from popt-1.13. Or have they?
> Not yet, but I am working on that, at least for Fedora Rawhide (-> F21).

Make peace with whether argv is allocated contiguously or with separate alloc's.
There's no easy answer: if compiled "traditionally", careful programming that
expects argv arrays to have malloc'd strings will have double free's.

And vice versa: valgrind will show "leaks" on older programs that "used to 
work" with popt.

No matter what: RPM+POPT is now internal again, again so that I don't have to 
with what distros choose to do with popt (its a rather small library).

73 de Jeff


73 de Jeff
> Greetings,
>  Robert
> <popt-1.16-man-page.patch>

POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to