Tanay Abhra <tanayabh@xxxxxxxxx> writes:
> diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt
> index 21f280c..0d8b99b 100644
> --- a/Documentation/technical/api-config.txt
> +++ b/Documentation/technical/api-config.txt
> @@ -155,6 +155,19 @@ as well as retrieval for the queried variable, including:
> Similar to `git_config_get_string`, but expands `~` or `~user` into
> the user's home directory when found at the beginning of the path.
>
> +`git_die_config(const char *key, const char *err, ...)`::
> +
> + First prints the error message specified by the caller in `err` and then
> + dies printing the line number and the file name of the highest priority
> + value for the configuration variable `key`.
Reviewed with a wider context, I notice that this entry alone lacks
the return type. I am assuming that this is just an oversight, and
adding 'void ' in front of the filename to match the next entry is
simple enough.
> +`void git_die_config_linenr(const char *key, const char *filename, int linenr)`::
> + ...
> +extern NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));
> ...
> +NORETURN __attribute__((format(printf, 2, 3)))
> +void git_die_config(const char *key, const char *err, ...)
> +{
My first reaction was that it might make the compiler unhappy to
declare that the "err" is a printf-like format string and then to
allow some callers to pass NULL to the function. My build however
does not seem to complain, so perhaps this is OK.
> + const struct string_list *values;
> + struct key_value_info *kv_info;
> +
> + if (err) {
> + va_list params;
> + va_start(params, err);
> + vreportf("error: ", err, params);
> + va_end(params);
> + }
> + values = git_config_get_value_multi(key);
> + kv_info = values->items[values->nr - 1].util;
> + git_die_config_linenr(key, kv_info->filename, kv_info->linenr);
> }
>
> /*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html