On Fri, 2008-01-25 at 18:41 -0800, Dennis Peterson wrote:
> Karsten Bräckelmann wrote:
> > On Fri, 2008-01-25 at 17:54 -0800, Dennis Peterson wrote:
> >> The sigs are full of unbound RE's. That's why scanning mbox mail files is
> >> pointless.
> >
> > Yes, I know. I contributed that fact to the thread a while ago...
> >
> > I do realize the ambiguity here -- there is no plural for 'mail'. :)
> > However, I am talking about a *single* mail. If I would have been
> > talking about mbox files, I'd have used that term.
> I've been out of town and haven't got caught up on all the world's history.
Dennis, now you're confusing me. :)
Nothing to catch up with, I've been referring to the thread "Getting
line numbers" back in Oct. Both of us have been discussing that topic.
> ClamAV's archives on on the list. Bounded (and anchored) RE's always
> run faster and they're more accurate. What's to lose?
I know about the archives, I've been a long time subscriber. Anyway...
What's to lose? Well, as per my OP, it just doesn't work. ClamAV freaks
out, when you start a hex signature with a (bounded) wildcard.
Besides, I'm not convinced bounded wildcards [1] actually do run faster
in clam. Haven't looked at the engines code, but given the rather
limited set of wildcards, I doubt it uses backtracking. And the bound
does impose another constraint while scanning the stream, no?
Good point about running faster when anchored, though. :)
guenther
[1] The doc talks about wildcards -- rightly so. They are no REs. The
only thing that at least comes close is the alternation.
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
