--- Begin Message ---
On 25/04/2024 12:25, Denis Ovsienko wrote:
> On Fri, 19 Apr 2024 11:18:47 -0700
> Guy Harris <ghar...@sonic.net> wrote:
>
>> On Apr 19, 2024, at 5:49 AM, Denis Ovsienko <de...@ovsienko.info>
>> wrote:
>>
>>> On Fri, 12 Apr 2024 18:49:05 -0700
>>> Guy Harris <ghar...@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).
>
> On a second thought, the best way to describe the desired result would
> be that from the library users' point of view the version macros should
> be easy to use correctly and difficult to use incorrectly. This would
> justify some inconvenience in the library code, if necessary.
>
> An advantage of correctly sized BCD versions is that two packed integer
> values compare in a straightforward way, so every end user does not
> have to remember how to compare two version triplets correctly. A
> disadvantage of BCD versions is the need to unpack them if one needs
> individual components.
>
> Perhaps the best balance would be in defining the individual version
> components as individual macros, and defining one-way "make this a BCD"
> and "make the current libpcap version a BCD" macros.
>
> For example, instead of
>
> // require libpcap >= 1.10.2
> PCAP_VERSION_MAJOR > 1 ||
> (PCAP_VERSION_MAJOR == 1 && PCAP_VERSION_MINOR > 10) ||
> (PCAP_VERSION_MAJOR == 1 && PCAP_VERSION_MINOR == 10 &&
> PCAP_VERSION_PATCH >= 2)
>
> the users could use the following:
>
> // require libpcap >= 1.10.2
> PCAP_VERSION_BCD_CURRENT >= PCAP_VERSION_BCD(1, 10, 2)
>
> (where the exact number of bits allocated to each version component and
> the definitions of PCAP_VERSION_BCD_CURRENT and PCAP_VERSION_BCD() are
> an internal detail so long as the same values compare the same in
> different versions of libpcap)
>
>>> 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:
>
> [...]
>
>> 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.
>
> Thank you for the overview of weak linking means. I suppose it would be
> best to keep out of this space to keep the task relatively manageable.
> The only use case for the C function I currently see is the
> command-line version tester.
>
>>> 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?
>
> Yes (as the tcpdump dependency would be). And not just the routines,
> but their behaviour, as some software could require.
>
>>>> 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.
>
> Let's aim for that then?
+1
--- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
