I've mentioned several times, so I might as well post the URI
to the POPT code review
http://rusty.ozlabs.org/
Rusty is also strongly advocating POPT 2.0 (when I asked
privately) and believes that "incompatibility" in an ABI
isn't as important an issue as future usage cases (my
paraphrase of his words).
There's very little I personally disagree with in the review, all the
wartlets in existing POPT code are well covered IMHO. The --help
handling is quite gross and (currently) is 30-50% of POPT code
with little (imho) justification or benefit.
The "fix" in POPT 2.0 involves dealing with wide character encoding
issues directly, atm POPT 1.0 is a confusing mess
of octet and character (possibly wide) display indexing to get --help
columns aligned.
The coding to fix --help display column is quite easy _IFF_ I
can achieve some "real world" reproducers and an acceptable
API/ABI design. The issues have been mentioned repeatedly over
the last couple of years on <popt-devel@rpm5.org> with no response.
FOr better or wiorse, I'm just a dumb 'merikkan with only en_US
as a native language. But that does not mean that I don't know
the C wide character interfaces quite well.
The splint annotations mentioned in the review are a different matter. While
the annotations are immensely pugly & intrusive, it is weeks of
staring at splint spewage that in fact led to POPT code
in its existing state.
The bottom line was: excellent code
ANd credit where it is due:
Erik Troan wrote most of POPT, I was just his packaging "bitch" ;-)
But I've long since re-written both POPT and RPM several times over, and mostly
adiabatically ...
Just in case:
adiabatically == legacy compatible
in my private jargon.
hth
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
