Tanay Abhra <tanay...@gmail.com> writes:

> @@ -1287,6 +1300,8 @@ static struct config_set_element 
> *configset_find_element(struct config_set *cs,
>  static int configset_add_value(struct config_set *cs, const char *key, const 
> char *value)
>  {
>       struct config_set_element *e;
> +     struct key_value_info *kv_info = xmalloc(sizeof(*kv_info));
> +     struct string_list_item *si;

I have this suspicion that we may want to eventually build a custom
"config_value_list" API that is very similar to what string_list
does, with the only difference from string_list being that the util
item of config_value_item (i.e. a parallel to string_list_item)
would not be a "void *" that points at anything, but is "struct
key_value_info" embedded within, so that we do not have to waste a
pointer and fragmented allocation.

I suspect such a config_value_list API must be built on top of a
kind of generics which C does not allow, which would mean we would
be doing some preprocessor macro tricks (similar to the way how
commit-slab.h allows different kinds of payload) that lets us build
a templated "string-list" API, discarding the existing
"string-list.[ch]" and replacing them with something like these two

    declare_generic_string_list(string_list, void *); /* in string-list.h */
    define_generic_string_list(string_list, void *); /* in string-list.c */

And at that point,

    declare_generic_string_list(config_value_list, struct key_value);
    define_generic_string_list(config_value_list, struct key_value);

would give us an API declaration and implementation that parallel
that of string-list, but with "struct key_value" in the util field
of each item.

But that kind of clean-up can come much later after this series
settles, and what this patch has is fine for now.
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

Reply via email to