Signed-off-by: Stefan Beller <sbel...@google.com>
---
Notes:
I do not quite recall a discussion about such fixes
when I started doing these fixes like 2 years ago.
As this is a main function of a subcommand the freed
memory is likely to have no impact as the process
is done soon, so then it gets freed by the OS which
is likey to be faster as the OS frees the whole pages
of the process. Also there is no expected memory
shortage as the process is going to be done soon
as opposed to fixing mem leaks early in the process.
An upside of fixes like this one is however to make
code analysis tools produce less noise, so narrowing
down the *real* issue may be easier.
I wonder if we could have a 'weak' free which does
nothing if git is compiled regularly and actually
frees the memory if it is build with a flag to tell
it to do so. This would help finding the real issues
as the noise goes down and it would still be 'fast'
as it could be when compiled for productive use.
On the other hand I don't like to have another
'invented here again' systemcall-ish function as
it would clutter the code and you'd have to remember
to use that weak free.
I dunno.
builtin/check-attr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 21d2bed..fa96356 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -182,5 +182,7 @@ int cmd_check_attr(int argc, const char **argv, const char
*prefix)
check_attr(prefix, cnt, check, argv[i]);
maybe_flush_or_die(stdout, "attribute to stdout");
}
+
+ free(check);
return 0;
}
--
2.3.0.81.gc37f363
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
