Jeff King <p...@peff.net> writes:
> The config callback functions get keys of the general form:
>
> section.subsection.key
>
> (where the subsection may be contain arbitrary data, or may
> be missing). For matching keys without subsections, it is
> simple enough to call "strcmp". Matching keys with
> subsections is a little more complicated, and each callback
> does it in an ad-hoc way, usually involving error-prone
> pointer arithmetic.
>
> Let's provide a helper that keeps the pointer arithmetic all
> in one place.
>
> Signed-off-by: Jeff King <p...@peff.net>
> ---
> No users yet; they come in future patches.
>
> cache.h | 15 +++++++++++++++
> config.c | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 48 insertions(+)
>
> diff --git a/cache.h b/cache.h
> index c257953..14003b8 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1164,6 +1164,21 @@ extern int git_config_include(const char *name, const
> char *value, void *data);
> #define CONFIG_INCLUDE_INIT { 0 }
> extern int git_config_include(const char *name, const char *value, void
> *data);
>
> +/*
> + * Match and parse a config key of the form:
> + *
> + * section.(subsection.)?key
> + *
> + * (i.e., what gets handed to a config_fn_t). The caller provides the
> section;
> + * we return -1 if it does not match, 0 otherwise. The subsection and key
> + * out-parameters are filled by the function (and subsection is NULL if it is
> + * missing).
> + */
> +extern int match_config_key(const char *var,
> + const char *section,
> + const char **subsection, int *subsection_len,
> + const char **key);
> +
I agree with Jonathan about the naming s/match/parse/.
After looking at the callers in your later patches, I think the
counted interface to subsection is probably fine. The caller can
check !subsection to see if it is a two- or three- level name, and
if (parse_config_key(var, "submodule", &name, &namelen, &key) < 0 ||
!name)
return 0;
is very easy to follow (that is the result of your 5th step).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
