> > I am fine with implementing either (?[flags]) or (?[flags]:[pattern) or
> > both.
>
> I'm going to just do the latter then, as it's a simple syntax change from
> what I currently have, whereas the other is more involved.
(this change is now pushed)
> I am fine with implementing either (?[flags]) or (?[flags]:[pattern) or
> both.
I'm going to just do the latter then, as it's a simple syntax change from
what I currently have, whereas the other is more involved.
Vern
___
bro-dev
On Fri, Jun 29, 2018 at 12:26:34PM -0700, Vern Paxson wrote:
> > Just so I have this right: it looks like the preferred would not be
> > /(?i foo)/ but rather /(?i)foo/, yes?
>
> Oh and to follow up on this, so in PCRE does /x((?i)bar)foo/ make the "foo"
> part case-insensitive too, or not? It's
> Just so I have this right: it looks like the preferred would not be
> /(?i foo)/ but rather /(?i)foo/, yes?
Oh and to follow up on this, so in PCRE does /x((?i)bar)foo/ make the "foo"
part case-insensitive too, or not? It's not obvious to me from the page
you pointed me at, and I don't have an
> Hum. Is there a reason why we come up with our own syntax for this?
No, just that I didn't have the other syntax on my radar. I was looking
at Snort & Suricata and didn't find this; I'm not a PCRE user myself.
It's simple to change, will do so now (though I think mine is slightly
more cool
On Fri, Jun 29, 2018 at 12:00:30PM -0700, Vern Paxson wrote:
> Once I wound up monkeying around with the internals of the pattern-matching
> code (to fix leaks, because Johanna [correctly] pushed back on adding the
> &/| operators for general use if they leaked, which an old ticket indicated
>
Once I wound up monkeying around with the internals of the pattern-matching
code (to fix leaks, because Johanna [correctly] pushed back on adding the
&/| operators for general use if they leaked, which an old ticket indicated
they would) ... I thought what-the-heck, it's time for supporting
