From: Nguyen Thai Ngoc Duy Date: Wed, 16 Nov 2011 08:37:34 GMT Subject: Re: [PATCH 0/3] avoiding unintended consequences of git_path() usage Message-ID: In-Reply-To: <20111116075955.GB13706@elie.hsd1.il.comcast.net> 2011/11/16 Jonathan Nieder : > 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