So far, two people have submitted patches to "fix" the "memory leak" in

icode_to_fcode() by having it free the bpf_insn array before returning a
pointer to it.  Add a comment to icode_to_fcode() explaining why this is
not a leak in icode_to_fcode(), it's a leak in their program, and
indicating how to fix the leak.

diff --git a/optimize.c b/optimize.c
index 98094a82d446f830550c6574e36c3c9067772585..5fc4926b79059cb5d24c0e2e26fedd1b04ac76fc 100644 (file)
--- a/optimize.c
+++ b/optimize.c
@@ -22,7 +22,7 @@
  */
 #ifndef lint
 static const char rcsid[] _U_ =
-    "@(#) $Header: /tcpdump/master/libpcap/optimize.c,v 1.87 2007-06-11 10:04:25 guy Exp $ (LBL)";
+    "@(#) $Header: /tcpdump/master/libpcap/optimize.c,v 1.88 2007-07-15 19:53:54 guy Exp $ (LBL)";
 #endif
 
 #ifdef HAVE_CONFIG_H
@@ -2227,6 +2227,20 @@ filled:
 /*
  * Convert flowgraph intermediate representation to the
  * BPF array representation.  Set *lenp to the number of instructions.
+ *
+ * This routine does *NOT* leak the memory pointed to by fp.  It *must
+ * not* do free(fp) before returning fp; doing so would make no sense,
+ * as the BPF array pointed to by the return value of icode_to_fcode()
+ * must be valid - it's being returned for use in a bpf_program structure.
+ *
+ * If it appears that icode_to_fcode() is leaking, the problem is that
+ * the program using pcap_compile() is failing to free the memory in
+ * the BPF program when it's done - the leak is in the program, not in
+ * the routine that happens to be allocating the memory.  (By analogy, if
+ * a program calls fopen() without ever calling fclose() on the FILE *,
+ * it will leak the FILE structure; the leak is not in fopen(), it's in
+ * the program.)  Change the program to use pcap_freecode() when it's
+ * done with the filter program.  See the pcap man page.
  */
 struct bpf_insn *
 icode_to_fcode(root, lenp)