--- Begin Message ---On Jan 22, 2023, at 9:59 AM, Denis Ovsienko via tcpdump-workers <tcpdump-workers@lists.tcpdump.org> wrote:> I have also removed AC_LBL_C_INLINE and a conditional substitute for > Tru64 pfopen() from tcpslice. Interestingly, tcpslice and tcpdump, > which don't call pfopen(), used to have this substitute, and libpcap, > which does call pfopen(), does not have it. That dates back to tcpdump 3.4. I don't know why they decided to compile pfopen() into tcpdump and tcpdslice if it's not in a system library, rather than compiling it into libpcap if it's not in a system library. Perhaps they wanted to be able to build versions of libpcap that would work both on Tru64 UNIX versions in which pfopen() is in a system library and versions in which it's not and all you have is pfopen.c source code under /usr/examples. I don't know what older versions those might be, and I suspect we have little if any reason to continue to make it possible to build tcpdump or tcpslice on those older versions - it looks as if Tru64 UNIX 4.x and 5.x have pfopen() in system libraries; according to https://en.wikipedia.org/wiki/Tru64_UNIX 4.0A through 4.0F all date back to the previous millennium. > In tcpdump it is a bit more entrenched, so I did not touch it yet. It looks as if you removed the pfopen() stuff from tcpdump's configure script in 43670fb635503e69cdbf8055134a0befb94d2e15. The AC_LBL_C_INLINE stuff is still there, but doesn't look *that* entrenched; are there any compilers that we need to support and that *don't* support C99 inline? If not, we could just remove the call from configure.ac and the definition from aclocal.m4.
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
