Re: [PATCH 0/3] avoiding unintended consequences of git_path() usage
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Nov 16, 2011, 08:37 UTC
- Message-ID
- <CACsJy8Di3ZrPdXh1Jf=PbLYRWwx-TEV78NzUukwaxA0xW=rSNg@mail.gmail.com>
- In-Reply-To
- <20111116075955.GB13706@elie.hsd1.il.comcast.net>
2011/11/16 Jonathan Nieder <jrnieder@gmail.com>:
Show 18 quoted lines
> Ramkumar Ramachandra wrote: >> Junio C Hamano wrote: > >>> Or perhaps http://thread.gmane.org/gmane.comp.version-control.git/184963/focus=185436 >> >> I noticed that sha1_to_hex() also operates like this. The >> resolve_ref() function is really important, but using the same >> technique for these tiny functions is probably an overkill > > I don't follow. Do you mean that not being confusing is overkill, > because the function is small that no one will bother to look up the > right semantics? Wait, that sentence didn't come out the way I > wanted. ;-) > > Jokes aside, here's a rough series to do the git_path -> > git_path_unsafe renaming. While writing it, I noticed a couple of > bugs, hence the two patches before the last one. Patch 2 is the more > interesting one.
Or perhaps - kill git_path(const char *fmt, ...) in favor of git_pathdup() companion - git_path(const char *path) maintains a small hash table to keep track of all returned strings based with "path" as key.
Out of 142 git_path() calls in my tree, 97 of them are in form git_path("some static string"). git_path() could learn to keep track of all generated strings while keep it convenient to use. I suspect with some macro magic, we can keep track of generated strings without a hash table.
-- Duy