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 popt-1.16):
.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 deal
with what distros choose to do with popt (its a rather small library).
73 de Jeff
73 de Jeff
Received on Sun Nov 24 18:18:50 2013