For computing moved lines, we feed the characters of each line into a hash. When we've been asked to ignore whitespace, then we pick each character using next_byte(), which returns -1 on end-of-string, which it determines using the start/end pointers we feed it. However our check of its return value treats "0" the same as "-1", meaning we'd quit if the string has an embedded NUL. This is unlikely to ever come up in practice since our line boundaries generally come from calling strlen() in the first place. But it was a bit surprising to me as a reader of the next_byte() code. And it's possible that we may one day feed this function with more exotic input, which otherwise works with arbitrary ptr/len pairs. Signed-off-by: Jeff King <peff@xxxxxxxx> --- I noticed that we make an extra copy of each line here, just to feed it to memihash! I guess "-w" is not a critical-performance code path, but this could be fixed if we could do memhash() incrementally (e.g., by putting the FNV state into a struct and letting callers "add" to it incrementally). Maybe an interesting #leftoverbits, though I'd want to see timing tests that show it's worth doing. diff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diff.c b/diff.c index 09081a207c..c4a669ffa8 100644 --- a/diff.c +++ b/diff.c @@ -782,7 +782,7 @@ static unsigned get_string_hash(struct emitted_diff_symbol *es, struct diff_opti strbuf_reset(&sb); while (ae > ap && isspace(ae[-1])) ae--; - while ((c = next_byte(&ap, &ae, o)) > 0) + while ((c = next_byte(&ap, &ae, o)) >= 0) strbuf_addch(&sb, c); return memhash(sb.buf, sb.len); -- 2.15.0.rc1.560.g5f0609e481
