Re: Dropping support in tcpdump for older versions of libpcap?

[Guy Harris <gharris () sonic net>]

On Apr 19, 2024, at 5:49 AM, Denis Ovsienko <denis () ovsienko info> wrote:

> On Fri, 12 Apr 2024 18:49:05 -0700
> Guy Harris <gharris () sonic net> wrote:

        ...

> Since tcpdump is the reference implementation of a program that uses
> libpcap, it may be a good occasion to improve the solution space such
> that other software can copy something that works well in tcpdump.  It
> is not entirely obvious the LIBPCAP_HAVE_PCAP_xxxx macros would be worth
> the burden of maintenance, but the version macros should be a
> straightforward improvement, something such as:
>
> #define PCAP_VERSION_MAJOR 1
> #define PCAP_VERSION_MINOR 11
> #define PCAP_VERSION_PATCHLEVEL 0
> #define PCAP_VERSION_AT_LEAST(a, b, c) ...
>
> (The GCC and Clang version checks in compiler-tests.h would be examples
> of a good macro structure; Sun C, XL C and HP C version checks look
> unwieldy and error-prone).

Presumably meaning that we should export version information in the way GCC and Clang do, rather than in the ways that 
Sun/Oracle C, XL C and HP C do, the latter being why we have to go through all that extra pain (they provide a single 
#define with the version number components packed in it - or two different defines in different versions as XL C does - 
rather than separate #defines for major and minor versions, as GCC and Clang do).

> There could be a run-time check as well:
>
> extern int pcap_version_at_least (unsigned char major, unsigned char
> minor, unsigned char patchlevel);

So how would that be used?

If a program is dynamically linked with libpcap, and includes calls to routines that were added in libpcap 1.12 or 
later, if you try to run it with libpcap 1.11, the run-time linker will fail to load it, as some symbols requested by 
the executable won't be present in the library. The only OS on which this can be made to work is macOS, with its weak 
linking mechanism:

        
https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html

although Apple didn't set up the header file to weakly link symbols until Xcode 15, and Sonoma was the first release 
built with Xcode 15, so I think the first OS in which you can arrange that the run-time linker not fail would be Sonoma.

With the macOS scheme, there are *run-time* checks for the OS version you're running on, although Apple have done 
rather a crap job of documenting the mechanism, especially as used in C and C++ code, where it's done with the 
__builtin_available() pseudo-function, e.g.:

        if (__builtin_available(macOS 10.12, *)) {
                if (clock_gettime(CLOCK_REALTIME, &value) == 0) {
                        printf("Realtime seconds: %ld\n", value.tv_sec);
                }
        } else {
                // clock_gettime not available!
                return 1;
        }

as per

        https://epir.at/2019/10/30/api-availability-and-target-conditionals/

If you *don't* do the check, you'll get, I think, a run-time failure if you try to call a routine that's not available; 
there's a compiler option, -Wunguarded-availability, to produce a warning if you make a call to a routine that's not 
available on the minimum-targeted OS version.

16-bit Windows also supported that - in the same way that macOS used to do it, with "the pointer to the function is 
NULL if a weakly-linked symbol isn't available" - but they decided that was too ugly, and got rid of it in 32-bit and 
64-bit Windows:

        https://devblogs.microsoft.com/oldnewthing/20160317-00/?p=93173

Apple probably also decided it was too ugly, and added __builtin_available() (and Objective-C @available, and something 
similar for Swift) as well as the compiler warning.

The Microsoft blog post indicates how you do this in Windows, namely by loading the library at run time with 
LoadLibrary() and attempting to get pointers to individual routines with GetProcAddress() and testing if the result is 
NULL; the same thing can be done on UN*Xes with dlopen() and dlsym().

But *all* of those require either run-time checks for a particular OS version in macOS, in cases where you're using the 
libpcap that comes with macOS, or require loading the library at run time, finding particular routines at run time, and 
checking at run time whether the routine was found.

> The latter could be available via a build helper binary, such as (using
> the binary operators from test(1) and version-aware comparison):
>
> pcap-version -ge 1 # same as 1 0 0
> pcap-version -ge 1 10 # same as 1 10 0
> pcap-version -ne 1 10 4
> pcap-version -eq 1 10 4
> pcap-version -ge 1 9 1 && pcap-version -le 1 9 3

So would this be used in a Makefile/configure script/CMakeFile.txt/etc. to check whether the libpcap on the system is 
sufficiently recent to include the routines your program needs, and fail if it isn't?

> > Is there any reason not to require libpcap 1.0 or later?  If there
> > is, is there any reason not to require libpcap 0.7 or later?
>
> Such use cases may exist, but I am not aware of any.

So my inclination would be to require libpcap 1.0 for tcpdump 5.0.

_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s