From: Jonathan Nieder <jrnieder@gmail.com>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH 3/3] for-each-ref: introduce %(upstream:track[short])
Date: Fri, 27 Sep 2013 15:18:45 -0700 [thread overview]
Message-ID: <20130927221845.GO9464@google.com> (raw)
In-Reply-To: <52459570.4030301@viscovery.net>
Johannes Sixt wrote:
> Am 9/27/2013 14:10, schrieb Ramkumar Ramachandra:
>> + v->s = xstrdup(buf);
>> + }
>
> These strdupped strings are leaked, right?
The convention seems to be that each refinfo owns its atom_value,
which owns its string that is kept on the heap. Except when it isn't
(e.g., "v->s = typename(obj->type);"). So at least this patch doesn't
make the muddle any worse. ;-)
A nice followup would be to consistently allocate atom_value.s on the
heap, check for a GIT_FREE_AT_EXIT envvar, and free the refinfos
if that envvar is set at exit. That would make sure that the code is
careful enough with memory to some day free some refinfo earlier when
there are many refs. Until that's ready, I think continuing to mix
and match like this (constant strings left as is, dynamically
generated strings on the heap) is the best we can do.
Thanks,
Jonathan
next prev parent reply other threads:[~2013-09-27 22:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 12:10 [PATCH 0/3] Juggling between hot branches Ramkumar Ramachandra
2013-09-27 12:10 ` [PATCH 1/3] for-each-ref: introduce %C(...) for color Ramkumar Ramachandra
2013-09-27 13:16 ` Phil Hord
2013-09-27 12:10 ` [PATCH 2/3] for-each-ref: introduce %(HEAD) asterisk marker Ramkumar Ramachandra
2013-09-27 12:10 ` [PATCH 3/3] for-each-ref: introduce %(upstream:track[short]) Ramkumar Ramachandra
2013-09-27 14:03 ` Phil Hord
2013-09-27 14:27 ` Ramkumar Ramachandra
2013-09-27 14:25 ` Johannes Sixt
2013-09-27 14:33 ` Ramkumar Ramachandra
2013-09-27 22:18 ` Jonathan Nieder [this message]
2013-09-27 16:06 ` Philip Oakley
2013-09-27 16:10 ` Ramkumar Ramachandra
2013-09-27 17:07 ` Philip Oakley
-- strict thread matches above, loose matches on Subject: below --
2013-10-31 9:46 [PATCH (resend) 0/3] Minor f-e-r enhacements Ramkumar Ramachandra
2013-10-31 9:46 ` [PATCH 3/3] for-each-ref: introduce %(upstream:track[short]) Ramkumar Ramachandra
2013-11-01 17:17 ` Junio C Hamano
2013-05-24 14:19 [PATCH v2 0/3] Towards a useable git-branch Ramkumar Ramachandra
2013-05-24 14:19 ` [PATCH 3/3] for-each-ref: introduce %(upstream:track[short]) Ramkumar Ramachandra
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=20130927221845.GO9464@google.com \
--to=jrnieder@gmail.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.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 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).