Re: [RFC/PATCH 2/3] wildmatch: add interface for precompiling wildmatch() patterns
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 24, 2017, 01:39 UTC
- Message-ID
- <xmqqshiq9naq.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170622213810.14785-3-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 13 quoted lines
> +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.