RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 02 Jan 2009 - 00:47:21 CET
Message-id: <D9AB8DA9-EC99-4972-8EB9-9AE151EE177E@mac.com>

On Jan 1, 2009, at 1:04 PM, Ralf S. Engelschall wrote:

>> A little help vetting the RE's please ;-) My eyes are already tired
>> from writing the toy script, RE's are more effective than XML at eye
>> gouging.
> I propose the following three entries in "macros"...
>    # STEP 1: Match the string and capture regex parts
>    #                      1          2           3             4
>    #                      X     ":"  X        "-"X          ":"X
>    %evr_tuple_match  ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-] 
> +))?$

A little more help please.

I'm using POSIX extended RE's.

With a single call to regexec(3), I'm seeing only 1 {rm_so, rm_eo}  
matched substring

What I'm expecting is what is in the toy sed script, that the tuple  
is parsed out and 4 substrings, not 1, are returned by a single  
of regexec(3), with sub-patterns that aren't matched being filled in  

I can certainly loop over regexec(3), proceeding to match the next  
if necessary.

But I've never seen nor used RE constructs like
ever in my life.

Note also that this is the 1st time *ever* that I've programmed a  
parser of this complexity in C. Not that there is anything very  
complicated in
pattern matching parsing, but you know what I mean.

73 de Jeff

  • application/pkcs7-signature attachment: smime.p7s
Received on Fri Jan 2 00:47:27 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.