This has been in the tree for a pretty long time, and usually
`if{up,down} -a` is a short-lived process.
Generally speaking, no memory leak > memory leak (even in short lived
processes).
The extra integer (typically) takes up 4 bytes, but gets freed off the
stack.
Relative to leaking (even a bit) for every interface, it's likely
preferable in memory constrained environments.
I've done minimal testing (making sure `ifup -a` and `ifdown -a` run
with the patch applied), but given the nature of the patch I cannot
foresee it introducing a new bug.
diff --git a/networking/ifupdown.c b/networking/ifupdown.c
index 8a6efc976..3a57d3a31 100644
--- a/networking/ifupdown.c
+++ b/networking/ifupdown.c
@@ -1177,6 +1177,7 @@ static int doit(char *str)
static int execute_all(struct interface_defn_t *ifd, const char *opt)
{
+ int res;
int i;
char *buf;
for (i = 0; i < ifd->n_options; i++) {
@@ -1193,8 +1194,10 @@ static int execute_all(struct interface_defn_t *ifd,
const char *opt)
* Don't "fix" this (unless newer Debian does).
*/
buf = xasprintf("run-parts /etc/network/if-%s.d", opt);
- /* heh, we don't bother free'ing it */
- return doit(buf);
+ res = doit(buf);
+
+ free(buf);
+ return res;
}
static int check(char *str)
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
