All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tanay Abhra <tanayabh@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] config.c: change the function signature of `git_config_string()`
Date: Tue, 22 Jul 2014 17:11:02 +0530	[thread overview]
Message-ID: <53CE4DCE.1010908@gmail.com> (raw)
In-Reply-To: <20140722110720.GA386@peff.net>



On 7/22/2014 4:37 PM, Jeff King wrote:
> On Tue, Jul 22, 2014 at 03:49:56AM -0700, Tanay Abhra wrote:
> 
>> `git_config_string()` output parameter `dest` is declared as a const
>> which is unnecessary as the caller of the function is given a strduped
>> string which can be modified without causing any harm.
>>
>> Thus, remove the const from the function signature.
> 
> You are correct that it is unnecessary. However, this patch alone is not
> sufficient because of the way const-ness in C works. If I have:
> 
>   static const char *some_global;
> 
> then with your patch, calling:
> 
>   git_config_string(&some_global, var, value);
> 
> will complain that we are passing a pointer to "const char *", not a
> pointer to "char *". And indeed, compiling with your patch introduces a
> ton of compiler warnings.
>

I had also thought that the compiler would raise lot of warnings but it didn't
on the first compile.
Now I checked again and now it complains a lot, maybe it because I was tinkering
with my config.mak, dunno.

> We would have to convert each of the variables we pass to it to:
> 
>   static char *some_global;
> 
> That's not so bad, but:
> 
>   static char *some_global = "some_default_value";
> 
> is wrong. Such a global sometimes points to const storage (i.e.,
> initially), and sometimes to allocated storage (if it was loaded from
> config). We simply keep the latter as a const pointer (since we would
> not bother to free it at the end of the program anyway), and that
> decision influences git_config_string, which is just a helper for
> setting such variables anyway.
> 
> So I would not mind lifting this unnecessary restriction on
> git_config_string, but I do not see a way to do it without making the
> rest of the code much uglier (and I do not see a particular advantage in
> modifying git_config_string here that would make it worth the trouble).
> 

Yes, you are right. This patch is the conclusion of discussion in [1].
I used the same function signature as git_config_string for
git_config_get_string() which lead to some ugly casts like

+git_config_get_string("imap.folder", (const char**)&imap_folder);

in imap-send.c patch and others. What should we do about such cases, I used
either an intermediate variable or casts but Junio commented that it would be better
if the dest parameter was a non-const and that it was a weakness of the config-set
API that demanded the dest to be a const pointer.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/253948/

  reply	other threads:[~2014-07-22 11:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22 10:49 [PATCH] config.c: change the function signature of `git_config_string()` Tanay Abhra
2014-07-22 11:07 ` Jeff King
2014-07-22 11:41   ` Tanay Abhra [this message]
2014-07-22 11:44   ` Matthieu Moy
2014-07-22 11:48     ` Tanay Abhra
2014-07-22 15:53     ` Junio C Hamano
2014-07-22 16:03       ` Matthieu Moy
2014-07-22 16:47   ` Junio C Hamano
2014-07-23  8:42     ` Matthieu Moy
2014-07-23 17:25       ` Junio C Hamano

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=53CE4DCE.1010908@gmail.com \
    --to=tanayabh@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.