git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tanay Abhra <tanayabh@gmail.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCH v3 2/3] config: add hashtable for config parsing & retrieval
Date: Tue, 24 Jun 2014 17:36:53 +0530	[thread overview]
Message-ID: <53A969DD.2030201@gmail.com> (raw)
In-Reply-To: <vpqtx7bn8ln.fsf@anie.imag.fr>

On 6/23/2014 5:25 PM, Matthieu Moy wrote:
> Tanay Abhra <tanayabh@gmail.com> writes:
>
>> +/* for NULL values, 'util' for each `string_list_item` is flagged as 1 */
>
> It's a void *, so just saying that it is flagged as 1 does not say how
> it's encoded. How about "... is an 'int *' pointing to the value 1".
>
> And actually, you can save one malloc by encoding the value directly in
> the util pointer itself like
>
> #define NULL_FLAG (void *)1
>
> 	item->util = NULL_FLAG;
>
> I find this a bit ugly, but I think Git already uses this in a few
> places (git grep 'void \*) *1' for examples).
>
> Or you can use a pointer to a single static value:
>
> static const int boolean_null_flag = 1; // Or even without = 1.
>
> and then
>
> 	item->util = &boolean_null_flag;
>

Thanks for the review. I will change the flag format to what you have
suggested. Instead of giving the users of the API the headache of
thinking about the flag, let me give you an alternative,

+const struct string_list *git_config_get_string_multi(const char *key)
+{
+	int i, *flag;
+	struct string_list *temp = config_cache_get_value(key);
+	if (!temp)
+		return NULL;
+	/* create a NODUP string list which can have NULL values */
+	struct string_list *l = xcalloc(1, sizeof(*l));
+	for(i=0; i < temp->nr; i++) {
+		flag = temp->items[i].util;
+		if (*flag)
+			string_list_append(l, NULL);
+		else
+			string_list_append(l, temp->items[i].string);
+	}
+	return l;
+}

Now the only headache for the user will be to free the string-list once
he is done with it. What do you think about this approach?

Also I have a doubt, when rewriting git_config() callers I saw a
curious case, when at the end of the callback they sometimes call
git_default_config().

For example in add.c,

static int add_config(const char *var, const char *value, void *cb)
{
	if (!strcmp(var, "add.ignoreerrors") ||
	    !strcmp(var, "add.ignore-errors")) {
		ignore_add_errors = git_config_bool(var, value);
		return 0;
	}
	return git_default_config(var, value, cb);
}

What should I do about this, should I change the default_config() calls
to git_config_get_string calls which I can easily do, if the values it 
is setting are not being set by any other callers.

For example in config.c,

static int git_default_core_config(const char *var, const char *value)
{
	/* This needs a better name */
	if (!strcmp(var, "core.filemode")) {
		trust_executable_bit = git_config_bool(var, value);
		return 0;
	}
	if (!strcmp(var, "core.trustctime")) {
		trust_ctime = git_config_bool(var, value);
		return 0;
	}
	if (!strcmp(var, "core.statinfo") ||
	    !strcmp(var, "core.checkstat")) {
--[snip]
variables like "core.filemode" or "core.statinfo" have been requested 
here only in the whole codebase, so I am safe to rewrite this function
with git_config_get_string, am I?

If not many callers (add_config...) behave like this. What should I
do with them?

Also, what are your views for the points Ramsay has raised.

Cheers,
Tanay Abhra.

  reply	other threads:[~2014-06-24 12:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 10:11 [PATCH v3 0/3] git config cache & special querying api utilizing the cache Tanay Abhra
2014-06-23 10:11 ` [PATCH v3 1/3] string-list: add string_list initialiser helper functions Tanay Abhra
2014-06-23 12:36   ` Torsten Bögershausen
2014-06-23 13:19     ` Tanay Abhra
2014-06-23 10:11 ` [PATCH v3 2/3] config: add hashtable for config parsing & retrieval Tanay Abhra
2014-06-23 11:55   ` Matthieu Moy
2014-06-24 12:06     ` Tanay Abhra [this message]
2014-06-25 20:25       ` Karsten Blees
2014-06-23 14:57   ` Ramsay Jones
2014-06-23 16:20     ` Tanay Abhra
2014-06-24 15:32       ` Ramsay Jones
2014-06-26 16:15         ` Matthieu Moy
2014-06-23 23:25     ` Junio C Hamano
2014-06-24  7:23       ` Tanay Abhra
2014-06-25 18:21         ` Junio C Hamano
2014-06-24  7:25       ` Tanay Abhra
2014-06-24 15:57       ` Ramsay Jones
2014-06-25 18:13         ` Junio C Hamano
2014-06-25 20:23           ` Karsten Blees
2014-06-25 20:53             ` Junio C Hamano
2014-06-26 17:37           ` Matthieu Moy
2014-06-26 19:00             ` Junio C Hamano
2014-06-26 19:19               ` Karsten Blees
2014-06-26 21:21                 ` Junio C Hamano
2014-06-27  8:19                   ` Karsten Blees
2014-06-27  8:19               ` Matthieu Moy
2014-06-27 17:13                 ` Junio C Hamano
2014-06-23 23:14   ` Junio C Hamano
2014-06-24 12:21     ` Tanay Abhra
2014-06-26 16:27       ` Matthieu Moy
2014-06-25 21:44   ` Karsten Blees
2014-06-26 16:43   ` Matthieu Moy
2014-06-23 10:11 ` [PATCH v3 3/3] test-config: add usage examples for non-callback query functions Tanay Abhra
2014-06-25 11:19   ` Eric Sunshine
2014-06-26  8:40     ` Tanay Abhra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A969DD.2030201@gmail.com \
    --to=tanayabh@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).