All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Tanay Abhra <tanayabh@gmail.com>
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 07:07:20 -0400	[thread overview]
Message-ID: <20140722110720.GA386@peff.net> (raw)
In-Reply-To: <1406026196-17877-1-git-send-email-tanayabh@gmail.com>

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.

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).

-Peff

  reply	other threads:[~2014-07-22 11:07 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 [this message]
2014-07-22 11:41   ` Tanay Abhra
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=20140722110720.GA386@peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tanayabh@gmail.com \
    /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.