git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 0/3] add strnncmp() function

From
Torsten Bögershausen <tboegi@web.de>
Date
Jun 17, 2014, 11:08 UTC
Message-ID
<53A02195.8080202@web.de>
In-Reply-To
<cover.1402990051.git.jmmahler@gmail.com>
On 2014-06-17 09.34, Jeremiah Mahler wrote:
Show 17 quoted lines
> 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.
  
Previous: Jeremiah MahlerNext: Jeremiah Mahler
Message 11 of 15 in “add strnncmp() function”
  1. 0/3 add strnncmp() functionJeremiah Mahler, Jun 17, 2014
  2. 1/3 add strnncmp() functionJeremiah Mahler, Jun 17, 2014
  3. Torsten BögershausenJun 17, 2014
  4. Jeremiah MahlerJun 17, 2014
  5. Erik Faye-LundJun 17, 2014
  6. Jeremiah MahlerJun 17, 2014
  7. Junio C HamanoJun 17, 2014
  8. Jeremiah MahlerJun 17, 2014
  9. 2/3 tree-walk: simplify via strnncmp()Jeremiah Mahler, Jun 17, 2014
  10. 3/3 unpack-trees: simplify via strnncmp()Jeremiah Mahler, Jun 17, 2014
  11. Torsten BögershausenJun 17, 2014
  12. Jeremiah MahlerJun 17, 2014
  13. Jonathan NiederJun 17, 2014
  14. Jeremiah MahlerJun 17, 2014
  15. Ondřej BílkaJun 18, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.