Explain that tools that complain about uninitialized data might be buggy.

[libpcap] / pcap-linux.c

diff --git a/pcap-linux.c b/pcap-linux.c
index 8e394f4feed164fbdc9927c8e0cdfb1c53b010fa..a72aecdcce16f5a0a28081a597839b6c59b6b0d2 100644 (file)
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -2285,6 +2285,30 @@ pcap_setfilter_linux_common(pcap_t *handle, struct bpf_program *filter,
                }
        }
 
+       /*
+        * NOTE: at this point, we've set both the "len" and "filter"
+        * fields of "fcode".  As of the 2.6.32.4 kernel, at least,
+        * those are the only members of the "sock_fprog" structure,
+        * so we initialize every member of that structure.
+        *
+        * If there is anything in "fcode" that is not initialized,
+        * it is either a field added in a later kernel, or it's
+        * padding.
+        *
+        * If a new field is added, this code needs to be updated
+        * to set it correctly.
+        *
+        * If there are no other fields, then:
+        *
+        *      if the Linux kernel looks at the padding, it's
+        *      buggy;
+        *
+        *      if the Linux kernel doesn't look at the padding,
+        *      then if some tool complains that we're passing
+        *      uninitialized data to the kernel, then the tool
+        *      is buggy and needs to understand that it's just
+        *      padding.
+        */
        if (can_filter_in_kernel) {
                if ((err = set_kernel_filter(handle, &fcode)) == 0)
                {