git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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