From: Junio C Hamano <gitster@pobox.com>
To: Alex Kuleshov <kuleshovmail@gmail.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] exec_cmd: system_path memory leak fix
Date: Sun, 23 Nov 2014 13:58:48 -0800 [thread overview]
Message-ID: <xmqq7fyly3xj.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <87sih9en65.fsf@gmail.com> (Alex Kuleshov's message of "Mon, 24 Nov 2014 01:19:29 +0600")
Alex Kuleshov <kuleshovmail@gmail.com> writes:
> Signed-off-by: Alex Kuleshov <kuleshovmail@gmail.com>
So this one does not change the contract between the caller and the
callee. It does not change the fact that you need to explain your
change, though. The story should read something like this:
system_path(): always return a volatile result
The function sometimes returns a newly allocated string and
sometimes returns a borrowed string, the latter of which the
callers must not free().
The existing callers all assume that the return value belongs to
the callee and most of them copy it with strdup() when they want
to keep it around. They end up leaking the returned copy when
the callee returned a new string.
Make sure all callers receive a volatile result, so that they do
not have to be worried about freeing the returned string.
There however are existing callers that are already broken, for
example, ...
Fixing these callers are done as separate patches, that can be
applied either before or after this patch.
Personally, as I already said, I think the approach the previous
version took (but not the implementation) to change the contract
between the callers and this function is probably a good idea in
the longer term. Leaking a bit by forgetting to convert a few
callers to free the returned values will not affect the correctness,
but making the returned value consistently more volatile will
expose existing breakage more often and will break codepaths that
happened to be working by accident.
Thanks.
next prev parent reply other threads:[~2014-11-23 21:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-23 13:56 GIT: [PATCH] exec_cmd: system_path memory leak fix 0xAX
2014-11-23 13:56 ` 0xAX
2014-11-23 14:01 ` 0xAX
2014-11-23 18:51 ` Junio C Hamano
2014-11-23 19:06 ` Alex Kuleshov
2014-11-23 19:19 ` Alex Kuleshov
2014-11-23 19:42 ` Jeff King
2014-11-23 20:07 ` Eric Sunshine
2014-11-23 21:58 ` Junio C Hamano [this message]
2014-11-24 7:02 ` Alex Kuleshov
2014-11-24 7:37 ` Junio C Hamano
2014-11-24 8:12 ` Alex Kuleshov
2014-11-24 13:11 ` Alexander Kuleshov
2014-11-24 14:00 ` Alex Kuleshov
2014-11-24 14:07 ` [PATCH] change contract between system_path and it's callers 0xAX
2014-11-24 19:33 ` Re*: " Junio C Hamano
2014-11-24 19:53 ` Alex Kuleshov
2014-11-24 20:20 ` Junio C Hamano
2014-11-24 20:50 ` Junio C Hamano
2014-11-25 6:45 ` Alexander Kuleshov
2014-11-25 7:04 ` Alexander Kuleshov
2014-11-25 17:55 ` Junio C Hamano
2014-11-25 18:03 ` Alexander Kuleshov
2014-11-25 18:24 ` [PATCH 1/1] " Alexander Kuleshov
2014-11-25 21:13 ` Junio C Hamano
2014-11-26 3:53 ` Alexander Kuleshov
2014-11-26 9:42 ` Alexander Kuleshov
2014-11-26 14:00 ` Alexander Kuleshov
2014-11-26 17:53 ` Junio C Hamano
2014-11-28 13:09 ` Philip Oakley
2014-11-25 20:20 ` Re*: [PATCH] " Junio C Hamano
2014-11-25 17:59 ` Alexander Kuleshov
2014-11-23 18:28 ` GIT: [PATCH] exec_cmd: system_path memory leak fix 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=xmqq7fyly3xj.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kuleshovmail@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.