From: "Krzysztof Kowalczyk" <kkowalczyk@gmail.com>
To: "Jeff King" <peff@peff.net>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] Optimize common pattern of alloc_ref from string
Date: Sat, 10 May 2008 17:30:56 -0700 [thread overview]
Message-ID: <7ce338ad0805101730n5b964a0em39d9fdcd9fc45f00@mail.gmail.com> (raw)
In-Reply-To: <20080510233918.GA315@sigill.intra.peff.net>
On Sat, May 10, 2008 at 4:39 PM, Jeff King <peff@peff.net> wrote:
> On Sat, May 10, 2008 at 04:26:58PM -0700, kkowalczyk@gmail.com wrote:
>
>> As a byproduct, fixes one place where string wasn't properly terminated.
>
> Great. Does this fix a user-visible bug? It would be nice to mention in
> the commit log _which_ place (though after reading the patch carefully,
> it looks like the one interpret_target) so that people looking at the
> commit later can understand exactly what was fixed.
It was a subtle memory corruption that wouldn't cause problems in
99.99% cases, but valgrind would probably catch it. And yes, it's the
interp_target().
>> - ref = alloc_ref(strlen(refname) + 1);
>> - strcpy(ref->name, refname);
>> + ref = alloc_ref_from_str(refname);
>
> So this turns a 2-line construct into a 1-line construct...
And avoids future prossible mistakes with not terminating the string,
like the one just commited.
>> +struct ref *alloc_ref_from_str(const char* str)
>> +{
>> + struct ref *ret;
>> + unsigned len = strlen(str) + 1;
>> + char *tmp = xmalloc(sizeof(struct ref) + len);
>> + ret = (struct ref*)tmp;
>> + memset(tmp, 0, sizeof(struct ref));
>> + tmp += sizeof(struct ref);
>> + memcpy(tmp, str, len);
>> + return ret;
>> +}
>
> But why do we need an 8-line function to do it?
>
> The only difference I can see over
>
> struct ref *alloc_ref_from_str(const char *str)
> {
> unsigned len = strlen(str) + 1;
> struct ref *ret = alloc_ref(len);
> memcpy(ret->name, str, len);
> return ret;
> }
>
> is that we avoid memsetting the name portion of the struct to 0 before
> copying to it. It seems like an unproven micro-optimization that makes
> it a bit harder to read.
You're absolutely right - it's a micro-optimization and your version
might be preferred for clarity. This is the first time I submit a
patch to git so I don't have a good feel for what kind of treadoffs
people find acceptable.
I should also mention that
static struct ref *try_explicit_object_name(const char *name)
{
unsigned char sha1[20];
struct ref *ref;
if (!*name) {
ref = alloc_ref(20);
strcpy(ref->name, "(delete)");
hashclr(ref->new_sha1);
return ref;
}
...
could also be replaced with alloc_ref_str() - I just wasn't 100% sure
if overallocating 10 bytes (20 - strlen("(delete)")) was just sloppy
code or does other code relies on that (which is unlikely and if true
then it wouldn't be good).
Regards,
-- kjk
next prev parent reply other threads:[~2008-05-11 0:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-10 23:26 [PATCH] Optimize common pattern of alloc_ref from string kkowalczyk
2008-05-10 23:39 ` Jeff King
2008-05-11 0:30 ` Krzysztof Kowalczyk [this message]
2008-05-11 8:07 ` Jeff King
2008-05-11 18:39 ` Junio C Hamano
2008-05-11 20:15 ` Krzysztof Kowalczyk
2008-05-11 22:02 ` Junio C Hamano
2008-05-11 15:32 ` Johannes Schindelin
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=7ce338ad0805101730n5b964a0em39d9fdcd9fc45f00@mail.gmail.com \
--to=kkowalczyk@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 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).