Hello Sergey,
* Sergey Poznyakoff meant to write on Tue, Aug 11, 2009 at 09:37:40PM CEST:
> > This would seem to still mis-characterizes patterns such as 'foo]'.
>
> Yes, of course. But this function is by no means thought to correctly
> catch all possible variations of wildcard patterns (one wou
Sergey Poznyakoff ha escrit:
> It may, in same cases, incorrectly recognize the former to be the
I wanted to say "in some cases", of course.
Regards,
Sergey
Hi Ralf,
> This would seem to still mis-characterizes patterns such as 'foo]'.
Yes, of course. But this function is by no means thought to correctly
catch all possible variations of wildcard patterns (one would have to
duplicate fnmatch for that). Its purpose is to give a rough estimate
on whethe
Hello Sergey,
* Sergey Poznyakoff wrote on Tue, Aug 11, 2009 at 03:07:03PM CEST:
> --- a/lib/exclude.c
> +++ b/lib/exclude.c
> +
> +/* Return true if str has wildcard characters */
> +bool
> +fnmatch_pattern_has_wildcards (const char *str, int options)
> +{
> + char *cset = "\\?*[]";
> + if (op
Hi Bruno,
Thanks for your remarks.
> Has the precedence handling changed, or is the test checking undefined
> behaviour?
Yes, it has changed. The first match determines whether the string
should be rejected or not. However, it does not rise any compatibility
concerns because none of the existing
Sergey Poznyakoff wrote:
> +test_exclude_LDADD = $(LDADD)
You need
test_exclude_LDADD = $(LDADD) @LIBINTL@
otherwise on non-glibc systems you get a link error, like this:
gcc -g -O2 -L/usr/local/cygwin/lib -o test-exclude.exe test-exclude.o
../gllib/libgnu.a
../gllib/libgnu.a(argmatch.o):
Sergey Poznyakoff wrote:
> > I would like to see some unit tests committed to this module before the
> > big optimization.
>
> Here they go:
This gives a lot of confidence. Thanks. One point, though: When running your
new tests against the former 'exclude' implementation, I get one failure:
PASS
Hi Bruno,
> 'is_fnmatch_pattern' is probably a misnomer, because its argument is
[...]
> Also, I'm surprised that this function does not take an 'options' argument.
> For example, the string 'ab\[cd\]' is constant if FNM_NOESCAPE is off, but
> non-constant if FNM_NOESCAPE is on.
Fixed both.
> I
Hello Sergey,
* Sergey Poznyakoff wrote on Sun, Aug 09, 2009 at 11:25:51PM CEST:
> The proposed patch considerably speed-ups the exclude module
> for large exclusion lists of non-wildcard patterns. Ok to push?
> --- a/lib/exclude.c
> +++ b/lib/exclude.c
> +/* Return true if str is a fnmatch patt
Bruno Haible ha escrit:
> Why does it not fit into two regexes / DFAs?
Yes, it would, provided that we translate fnmatch patterns to regexps.
> EXCLUDE_WILDCARDS on: 'a?b*' -> 'a.b.*'
> EXCLUDE_WILDCARDS off: 'a?b*' -> 'a[?]b[*]'
> EXCLUDE_ANCHORED on: 'a?b' -> '^a.b$'
>
Sergey Poznyakoff wrote:
> By the way, I am also experimenting with the idea of re-implementing
> the exclude module using DFA, i.e. regarding the entire exclude list
> as a set of regular language definitions and creating a DFA for each
> of them (it is a *set* of definitions, because its parts ca
Hi Bruno,
> 'is_fnmatch_pattern' is probably a misnomer, because its argument is
> by definition already an fnmatch pattern. What the function is testing is
> whether it contains wildcard characters
Yes, indeed.
> Btw, this function does not handle multiple adjacent backslashes correctly,
> i.e.
Hello Sergey,
> The proposed patch considerably speed-ups the exclude module
> for large exclusion lists of non-wildcard patterns.
Great idea!
'is_fnmatch_pattern' is probably a misnomer, because its argument is
by definition already an fnmatch pattern. What the function is testing is
whether it
Hello,
The proposed patch considerably speed-ups the exclude module
for large exclusion lists of non-wildcard patterns. Ok to push?
>From 5421774438de3a67d89f988a0cd735e19a4cafd4 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff
Date: Mon, 10 Aug 2009 00:14:45 +0300
Subject: [PATCH] Optimize excl
14 matches
Mail list logo
