git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: git@vger.kernel.org, peff@peff.net, bmwill@google.com
Subject: Re: [PATCH 2/4] Clarify return value ownership of real_path and read_gitfile_gently
Date: Tue, 26 Sep 2017 14:01:59 +0900	[thread overview]
Message-ID: <xmqqmv5iaw8o.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170925155927.32328-3-hanwen@google.com> (Han-Wen Nienhuys's message of "Mon, 25 Sep 2017 17:59:25 +0200")

Han-Wen Nienhuys <hanwen@google.com> writes:

>>Subject: Re: [PATCH 2/4] Clarify return value ownership of real_path and read_gitfile_gently

We try to make "shortlog --no-merges" output consistently say what
area the change is about, followed by a colon, followed by a short
description.

> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> ---
>  abspath.c | 3 +++
>  setup.c   | 3 ++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/abspath.c b/abspath.c
> index 708aff8d4..792a2d533 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -202,6 +202,9 @@ char *strbuf_realpath(struct strbuf *resolved, const char *path,
>  	return retval;
>  }
>  
> +/* Resolve `path` into an absolute, cleaned-up path. The return value
> + * comes from a global shared buffer and should not be freed.
> + */
>  const char *real_path(const char *path)
>  {
>  	static struct strbuf realpath = STRBUF_INIT;

The part about "what it does" is a good thing to have here, but I do
not think the second sentence adds much if it stays here (if the
comment were in a header file far from implementation, then it is a
different matter).  Besides, "should not be freed" is not the only
important thing---it is already implied by the function returning
"const char *" (i.e. the caller/receiver does not own it).  It will
stay valid only until the next call, so the caller needs to xstrdup()
it if it wants to keep the value.  That is equally important.

But quite honestly, that pattern appears very often in our codebase
(all users of get_pathname() share the same characteristics) that
these details (i.e. do not free, expect the buffer to be recycled)
probaly is not worth it.  Mentioning that the returned value is in a
shared buffer for short-term use would be sufficient.

> diff --git a/setup.c b/setup.c
> index 6d8380acd..31853724c 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -541,7 +541,8 @@ void read_gitfile_error_die(int error_code, const char *path, const char *dir)
>  
>  /*
>   * Try to read the location of the git directory from the .git file,
> - * return path to git directory if found.
> + * return path to git directory if found. The return value comes from
> + * a shared pool and should not be freed.

OK, the returned value comes from the return value of real_path(),
so the early half of the new warning is worth having.  "should not
be freed" is both extraneous (for those who are already aware of the
common pattern in our codebase) and insufficient (for those who are
not yet).

Thanks.

>   *
>   * On failure, if return_error_code is not NULL, return_error_code
>   * will be set to an error code and NULL will be returned. If

  parent reply	other threads:[~2017-09-26  5:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25 15:59 [PATCH 0/4] Assorted comment fixes Han-Wen Nienhuys
2017-09-25 15:59 ` [PATCH 1/4] Fix typo in submodule.h Han-Wen Nienhuys
2017-09-25 15:59 ` [PATCH 2/4] Clarify return value ownership of real_path and read_gitfile_gently Han-Wen Nienhuys
2017-09-25 17:24   ` Brandon Williams
2017-09-26  5:01   ` Junio C Hamano [this message]
2017-09-25 15:59 ` [PATCH 3/4] Document submodule_to_gitdir Han-Wen Nienhuys
2017-09-25 17:25   ` Brandon Williams
2017-09-25 15:59 ` [PATCH 4/4] Move documentation of string_list into string-list.h Han-Wen Nienhuys
2017-09-25 17:40   ` Brandon Williams
2017-09-25 20:05     ` Stefan Beller
2017-09-27 15:59     ` Andrey Rybak
2017-09-26  5:06   ` Junio C Hamano
2017-09-26  5:22     ` Junio C Hamano
2017-09-26 11:22       ` Han-Wen Nienhuys

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqmv5iaw8o.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=hanwen@google.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).