On Thu, Sep 09, 2010 at 02:33:15PM -0500, Brandon Casey wrote: > On 09/09/2010 02:21 PM, Jeff King wrote: > > On Thu, Sep 09, 2010 at 02:02:46PM -0500, Brandon Casey wrote: > > > >> From: Brandon Casey <drafnel@xxxxxxxxx> > >> > >> Generally, trailing space is removed from the string matched by the > >> xfuncname patterns. The exception is when the matched string exceeds the > >> length of the fixed-size buffer that it will be copied in to. But, a > >> string that exceeds the buffer can still contain trailing space in the > >> portion of the string that will be copied into the buffer. So, simplify > >> this code slightly, and just perform the trailing space removal always. > > > > Hrm. So we are cutting off trailing space that might have been > > non-trailing space in their original string? It is hard to argue that is > > much worse than truncating the original string in the first place. But I > > really wonder whether we should be silently truncating anything, and not > > just dying or somehow handling this better? > > > > If I understand what is going on (and I'm not sure that I do), are we > > silently producing bogus word-diffs in the face of really long lines? > > I don't think this function is used to do the word-diffs. Unless I'm > missing something, ff_regexp is only used to do the funcname matching to > produce the hunk header string. An 80-byte buffer is used to hold > that string. So, the trimming is performed on what is effectively a > comment. Ah, OK, that makes a lot more sense. Then yeah, we should always be trimming trailing whitespace from the result, so your patch is good. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html