Jeff King <peff@xxxxxxxx> writes: > The simplest fix here is to just pass "ret" (which we know to be NULL) > to the follow-up realloc(). That does mean that a system which _doesn't_ > free the original pointer would leak it. But that interpretation of the > standard seems unlikely (if a system didn't deallocate in this case, I'd > expect it to simply return the original pointer). If it turns out to be > an issue, we can handle the "!size" case up front instead, before we > call realloc() at all. > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > wrapper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/wrapper.c b/wrapper.c > index 4ff4a9c3db..b0d375beee 100644 > --- a/wrapper.c > +++ b/wrapper.c > @@ -120,7 +120,7 @@ void *xrealloc(void *ptr, size_t size) > memory_limit_check(size, 0); > ret = realloc(ptr, size); > if (!ret && !size) > - ret = realloc(ptr, 1); > + ret = realloc(ret, 1); The original does look bogus. It however may be easier to reason about if we used malloc(1) in the fallback path for "we got NULL after asking for 0-byte" instead. I would have a hard time guessing the reason why we are reallocating NULL without going back to this commit, reading the log and seeing the original to see that the reason why we didn't use malloc() but realloc() is we aimed for a minimum change, if I encounter this code after I forgot this discussion. Thanks.
