Re: [RFC/PATCH 2/3] wildmatch: add interface for precompiling wildmatch() patterns

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux