Similar to the previous commit, avoid passing `strbuf_attach()` the same value for `len` and `alloc` by switching to `strbuf_add()`. This avoids a subtle allocate+copy+free dance in favour of a much more obvious one. Unlike in the previous commit, for this site, I know that it's not safe to pass in "len, len + 1". Trying that makes `strbuf_attach()` write a trailing '\0' at `result.ptr[len]`. Running our test suite with AddressSanitizer will spot an out-of-bounds write due to this. Signed-off-by: Martin Ågren <martin.agren@xxxxxxxxx> --- rerere.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rerere.c b/rerere.c index 9281131a9f..c3e3714824 100644 --- a/rerere.c +++ b/rerere.c @@ -1007,7 +1007,8 @@ static int handle_cache(struct index_state *istate, else io.io.output = NULL; strbuf_init(&io.input, 0); - strbuf_attach(&io.input, result.ptr, result.size, result.size); + strbuf_add(&io.input, result.ptr, result.size); + free(result.ptr); /* * Grab the conflict ID and optionally write the original -- 2.26.1