git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Jeremiah Mahler <jmmahler@gmail.com>,
	Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 0/3] add strnncmp() function
Date: Tue, 17 Jun 2014 13:08:05 +0200	[thread overview]
Message-ID: <53A02195.8080202@web.de> (raw)
In-Reply-To: <cover.1402990051.git.jmmahler@gmail.com>

On 2014-06-17 09.34, Jeremiah Mahler wrote:
> Add a strnncmp() function which behaves like strncmp() except it takes
> the length of both strings instead of just one.
> 
> Then simplify tree-walk.c and unpack-trees.c using this new function.
> Replace all occurrences of name_compare() with strnncmp().  Remove
> name_compare(), which they both had identical copies of.
> 
> Version 2 includes suggestions from Jonathan Neider [1]:
> 
>   - Fix the logic which caused the new strnncmp() to behave differently
> 	from the old version.  Now it is identical to strncmp().
> 
>   - Improve description of strnncmp().
> 
> Also, strnncmp() was switched from using memcmp() to strncmp()
> internally to make it clear that this is meant for strings, not
> general buffers.
I don't think this is a good change, for 2 reasons:
- It changes the semantics of existing code, which should be carefully
  reviewed, documented and may be put into a seperate commit.
- Looking into the code for memcmp() and strncmp() in libc,
  I can see that memcmp() is written in 13 lines of assembler,
  (on a 386 system) with a fast
    repz cmpsb %es:(%edi),%ds:(%esi)
  working as the core engine.
  
  strncmp() uses 83 lines of assembler, because after each comparison
  the code needs to check of the '\0' in both strings.
- I can't see a reason to replace efficient code with less efficient code,
  so moving the old function "as is" into a include file, and declare
  it "static inline" could be the first step.

  Having code inline may open the door for the compiler to decide,
  "Oh, I know exactly what memcmp() does, so I through in a handfull
  of lines assembly code, instead of calling memcmp() from libc".


And another thing:
 What does cache_name_compare(name, namelen, ce->name, len))
 in name-hash.c do?
 Isn't that the same function ?

I like strnncmp() better than 
cache_name_compare() or name_compare(),
but I agree with Erik here that strnncmp() has the potential to
become a name clash some day, so that git_strnncmp() may be better.

Thanks for the effort, cleaning up is needed.


  

  parent reply	other threads:[~2014-06-17 11:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17  7:34 [PATCH v2 0/3] add strnncmp() function Jeremiah Mahler
2014-06-17  7:34 ` [PATCH v2 1/3] " Jeremiah Mahler
2014-06-17  8:23   ` Torsten Bögershausen
2014-06-17 15:48     ` Jeremiah Mahler
2014-06-17  9:09   ` Erik Faye-Lund
2014-06-17 15:49     ` Jeremiah Mahler
2014-06-17 17:55   ` Junio C Hamano
2014-06-17 19:27     ` Jeremiah Mahler
2014-06-17  7:34 ` [PATCH v2 2/3] tree-walk: simplify via strnncmp() Jeremiah Mahler
2014-06-17  7:34 ` [PATCH v2 3/3] unpack-trees: " Jeremiah Mahler
2014-06-17 11:08 ` Torsten Bögershausen [this message]
2014-06-17 15:49   ` [PATCH v2 0/3] add strnncmp() function Jeremiah Mahler
2014-06-17 17:48     ` Jonathan Nieder
2014-06-17 19:09       ` Jeremiah Mahler
2014-06-18 10:33   ` Ondřej Bílka

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=53A02195.8080202@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=jmmahler@gmail.com \
    --cc=jrnieder@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 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).