On Sun, Aug 25, 2013 at 04:45:50AM -0400, Jeff King wrote:
> This is the minimal fix. Another option would be to switch
> read_mailmap_buf to read_mailmap_string, and I think we could even get
> away with avoiding the extra allocation/copy in the loop (because
> read_mailmap_line seems to cope with newline-or-EOS just fine). But it
> may be better to save that for 'master'.
Hmm, actually, this isn't quite true. read_mailmap_line does handle the
optional trailing newline properly, but the underlying parsing routines
really do want to see a NUL at the end of each line (because they came
from code that just calls fgets). So we really do want to tie off each
line. But given that our only caller is handing us blob contents which
get immediately freed, we could still do that without an extra
allocation if:
1. We make it clear that the input must be NUL-terminated (i.e., by
renaming the function and dropping the len parameter).
2. We drop the "const" from the buf parameter so that we can simply
terminate each line as we go.
I'll see what the patch looks like.
-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