Re: [PATCH 2/4] dir.c::match_basename(): pay attention to the length of string parameters
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 26, 2013, 20:49 UTC
- Message-ID
- <7v7gktubsp.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130326203914.GA29167@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> I timed this doing "git archive HEAD" on webkit.git before and after. It > actually ended up not mattering much (I think because it is only the > directories which are affected, not each individually path, so it's a > much smaller number than you'd think). The best-of-five timing was > slightly slower, but was within the noise.
Interesting. Because "archive" has to incur a large I/O cost anyway, I expected extra allocation for correctness for only the directory paths would be dwarfed in the noise.
I actually care more about cases other than "archive", though. Do we even feed directory paths to the machinery?
> So I do still think it would make sense to go to a byte-limited version > of fnmatch eventually, just for code cleanliness and predictability of > performance, but this is really not a bad solution in the interim.
Yes, what we do with wildmatch is a separate issue for 'master' and upwards.