RPM Community Forums

Mailing List Message of <popt-devel>

Parsing ASN.1 with POPT 2.0? (was Re: [CVS] RPM: popt/ configure.ac)

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 23 Jul 2010 - 19:20:27 CEST
Message-id: <3A6B7AD5-D244-47A8-B1C9-2910AB581401@mac.com>

On Jul 23, 2010, at 1:04 PM, devzero2000 wrote:

> On Fri, Jul 23, 2010 at 6:22 PM, Jeff Johnson <n3npq@mac.com> wrote:
>> Careful here ...
>> 
>> ... popt is used on many many more platforms than RPM.
>> 
>> The issue that I see is invariably that GCC options are often
>> not present in older compilers.
>> 
>> The right fix (imho) is to set CFLAGS outside
>> of AutoFu. Otherwise you end-up chasing down
>> GCC versions with logic to set options dependent
>> on version which becoems quite hard to manage.
> Not a problem, IHMO. The command adds the flags needed only if the
> compiler understands them, compiling a test program as usual.
> If I run configure on a platform with an older GCC there are no
> problems (also on another operating system .e.g. AIX ).
> 
> It's ok for you ?
> 

My only criteria with POPT patches is
	The "make check" MUST succeed.
(and hopefully without shortcuts and hack-o-rounds but
there are times that hackery is needed too.)

>> 
>> I'm not averse to what you are doing whatsoever,
>> just, well, the "fix" for a reported problem will
>> be to revert.
>> 
> I want to participate more actively.   I hope that what I do, however
> trivial, its usefulness anyway. If not please tell
> and i will stop.
> 

Go for it!

I may critique but I do not wish to forbid anything.

FL/OSS developers are really good at finding flaws, less good
at identifying features/design.

So I have no worries about regressions/mistakes.

> And who knows if in the second edition of Oreilly "Beautiful testing"
> will be cite also popt :=) other that clamav.
> 

;-)

>> BTW, there's -fPIE that's likely more important for
>> an Elf library than almost any other security measure.
> Well also the other flags are important.
> 
>> track whether that's in popt or not, ignore my aside if -fPIE
>> is present.
> I will add in a moment, it is not present now and i miss it.

New topic:

I've been debating whether to use POPT as an ASN.1 parser in POPT-2.0.

Both POPT and ASN.1 are TLV (type/length/value) table driven
parsers even if the usage cases are quite different (options & args != RPC marshalling).

Mostly what I would attempt is to map either the libtasn1 format (its
a tree of named nodes in an array) or the NSS ASN.1 format (which
is directives not unlike POPT_ARGFLAG_FOO but without named nodes)
into a popt table.

Then I'd stub in a method to substitute an ASN.1 blob for parsing
rather that argv[arc] as POPT currently uses.

I'd likely duplicate the methods used while parsing argv[argc] into
a different code path before attempting to unify (gulp) ARGV and ASN.1
parsing within the same routines.

The ulterior motive for attempting ASN.1 parsing would be to look carefully
at vectorizing POPt with callbacks. If I can trick POPT into parsing
ASN.1 I'm almost positive that POPT parsing will be quite a bit more
general than currently.

Opinions?
Received on Fri Jul 23 20:21:42 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.