mailmap: handle mailmap blobs without trailing newlines
commitf972a1658a30809db113a3c486b1fe95b56633bf
authorJeff King <peff@peff.net>
Wed, 28 Aug 2013 01:41:39 +0000 (27 21:41 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 28 Aug 2013 19:33:32 +0000 (28 12:33 -0700)
tree9c6b5ddac263d071ce0be41c1116a585edda5ffc
parenta3bc3d070cacf07dbe11b4bfec57554c8bbf1957
mailmap: handle mailmap blobs without trailing newlines

The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:

    const char *end = strchrnul(buf, '\n');
    unsigned long linelen = end - buf + 1;

But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.

We could fix it with:

    unsigned long linelen = end - buf + !!*end;

but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.

Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.

This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mailmap.c
t/t4203-mailmap.sh