Re: [PATCH 5/5] xdiff: NUL-terminate buffers read by read_mmfile()

Patrick Steinhardt [off-list ref] writes:

On Tue, Sep 29, 2026 at 02:55:04AM -0400, Jeff King wrote:

quoted

Since an mmfile_t is a ptr/len pair, our read_mmfile() allocates exactly
the number of bytes we claim to store. But in many other places in Git,
we add an extra NUL "just in case", which can help avoid read overruns
due to off-by-ones or the use of string functions.

I don't know of any path that would benefit from this, but I noticed it
while converting ll_ext_merge() to use read_mmfile(), since its original
code did add a NUL byte (even though I cannot find any case where it
would have mattered). Let's teach read_mmfile() to add this defensive
NUL; it probably doesn't help anything, but nor should it hurt.

Note that the matching read_mmblob() doesn't need the same treatment.
Its buffers already have a NUL from the object-reading code (which uses
the same defensive trick).

As a bonus, we can get rid of the hack in read_mmfile() to handle empty
files by allocating a single byte.

Signed-off-by: Jeff King <redacted>
---
This one is obviously optional, which is why I put it last.
...
-	ptr->ptr = xmalloc(sz ? sz : 1);
+	ptr->ptr = xmallocz(sz);

I was staring at this code a while before I noticed the added `z` at the
end of this function.

I had the same reaction yesterday.  The proposed log message never
said how it added the extra NUL (or for that matter, it wasn't clear
if it actually did the adding).  The usual imperative "Add the same
'just in case' NUL by using xmallocz()." would have helped a lot.