On Jan 6, 2008 3:40 PM, Guy Harris <[EMAIL PROTECTED]> wrote: > Fulko Hew wrote: > > > I think the code is better when its more > > obvious, segregated and less intrusive. > > I've checked into the main and 1.0 branches changes to make it even more > segregated and less intrusive. If pcap-linux.c was compiled with SITA > support, very little of the regular Linux capture code was used, so I > just removed the SITA support code from pcap-linux.c and moved it to > pcap-sita.c, and make "--with-sita" cause libpcap to be compiled with > pcap-sita.c rather than pcap-linux.c. > > In addition, pcap-sita.c was using "ulong" in cases where it wanted a > 32-bit data type (the "l" in "ntohl()" and "htonl()" really means > "32-bit", not "long"; the use of "l" is historical and refers to the > fact that, on L32 and LP32 platforms, where "int" is 16 bits, you need > "long" for 32 bits); I changed it to use the official libpcap 32-bit > data type, bpf_u_int32, as "long" could well be 64 bits. > > As a site effect, I was able to at least compile the SITA code on Mac OS > X, so I updated README.sita to note that, at least in theory, the SITA > code might no longer require Linux. There were some compiler warnings > generated; I fixed those. (To get libpcap to compile with GCC warnings, > create a ".devel" file in the top-level source directory and re-run the > configure script.) There are still some warnings: > > ./pcap-sita.c: In function 'acn_findalldevs': > ./pcap-sita.c:415: warning: 'port' may be used uninitialized in this > function > ./pcap-sita.c:414: warning: 'proto' may be used uninitialized in this > function > ./pcap-sita.c: At top level: > ./pcap-sita.c:77: warning: 'errorString' defined but not used > ./pcap-sita.c:86: warning: 'dump_interface_list' defined but not used > ./pcap-sita.c:127: warning: 'dump_interface_list_p' defined but not used > ./pcap-sita.c:147: warning: 'dump_unit_table' defined but not used > ./pcap-sita.c:234: warning: 'find_nth_interface_name' defined but not used > ./pcap-sita.c:375: warning: 'acn_freealldevs' defined but not used > > Does the fact that acn_freealldevs() isn't used mean that memory might > leak?
No. Upon reflection (although I'm still chasing my other issue)... these routines were all test routines. I had built a harness to easily debug/test my changes and enhancements without having to rebuild wireshark (primarily my SITA interface discovery mechanism) . And in order to allow me to (easily) re-run the tests, I needed a routine like acn_freealldevs() to allow the harness to clean_up after itself. In retrospect, the kernel closes all open sockets upon normal exit, but I decided to do it the friendly way. In conclusion, no... not being called does not infer a potential memory leak. But as previously mentioned, I am pursuing a different situation where some sockets are not closed, but this only 'appears to' happen when run on certain Linux kernels. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
