Re: [RFC/PATCH 2/3] wildmatch: add interface for precompiling wildmatch() patterns
Ævar Arnfjörð Bjarmason writes: > On Sat, Jun 24 2017, Junio C. Hamano jotted: > >> Is the far-in-the-future vision to make this the other way around? >> That is, this being scaffolding, wildmatch_match() which is supposed >> to be precompiled match actually uses wildmatch() as its underlying >> engine, but when a viable compilation machinery is plugged in, the >> wildmatch_match() that takes a precompiled pattern will call into >> the machinery to execute the compiled pattern, and wildmatch() will >> be reimplemented as "compile, call wildmatch_match() once and >> discard" sequence? > > Exactly there would be no functional difference in the results, only > fixed overhead. OK, good! Thanks.
Re: [RFC/PATCH 2/3] wildmatch: add interface for precompiling wildmatch() patterns
On Sat, Jun 24 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> +struct wildmatch_compiled *wildmatch_compile(const char *pattern, unsigned
>> int flags)
>> +{
>> +struct wildmatch_compiled *code = xmalloc(sizeof(struct
>> wildmatch_compiled));
>> +code->pattern = xstrdup(pattern);
>> +code->flags = flags;
>> +
>> +return code;
>> +}
>> +
>> +int wildmatch_match(struct wildmatch_compiled *code, const char *text)
>> +{
>> +return wildmatch(code->pattern, text, code->flags);
>> +}
>
> Is the far-in-the-future vision to make this the other way around?
> That is, this being scaffolding, wildmatch_match() which is supposed
> to be precompiled match actually uses wildmatch() as its underlying
> engine, but when a viable compilation machinery is plugged in, the
> wildmatch_match() that takes a precompiled pattern will call into
> the machinery to execute the compiled pattern, and wildmatch() will
> be reimplemented as "compile, call wildmatch_match() once and
> discard" sequence?
Exactly there would be no functional difference in the results, only
fixed overhead.
wildmatch() would be the one-off lazy interface and
wildmatch_{compile,match,free}(), just like how you can have a wrapper
function that calls regcomp() followed by regexec() & regfree(), but
it's better to structure your code so you're not compiling & freeing the
pattern all the time.
Right now of course there's no difference in the behavior, and a
trivially more overhead with the extra xstrdup() & free(), but I wanted
to split up the discussion of the semantics of the interface from any
actual behavior change in wildmatch() which would make use of it further
down the line.
> Otherwise I'd be worried about wildmatch() vs wildmatch_match()
> introducing subtle behaviour differences that leads to hard to debug
> problems.
Re: [RFC/PATCH 2/3] wildmatch: add interface for precompiling wildmatch() patterns
Ævar Arnfjörð Bjarmason writes:
> +struct wildmatch_compiled *wildmatch_compile(const char *pattern, unsigned
> int flags)
> +{
> + struct wildmatch_compiled *code = xmalloc(sizeof(struct
> wildmatch_compiled));
> + code->pattern = xstrdup(pattern);
> + code->flags = flags;
> +
> + return code;
> +}
> +
> +int wildmatch_match(struct wildmatch_compiled *code, const char *text)
> +{
> + return wildmatch(code->pattern, text, code->flags);
> +}
Is the far-in-the-future vision to make this the other way around?
That is, this being scaffolding, wildmatch_match() which is supposed
to be precompiled match actually uses wildmatch() as its underlying
engine, but when a viable compilation machinery is plugged in, the
wildmatch_match() that takes a precompiled pattern will call into
the machinery to execute the compiled pattern, and wildmatch() will
be reimplemented as "compile, call wildmatch_match() once and
discard" sequence?
Otherwise I'd be worried about wildmatch() vs wildmatch_match()
introducing subtle behaviour differences that leads to hard to debug
problems.
