Re: NetBSD CI breakage

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Wed, 13 Jul 2022 23:16:18 -0700
>
> On Jul 10, 2022, at 2:48 PM, Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > The last CI build of the libpcap-1.10 branch failed on netbsd-aarch64
> > because the latter now uses GCC 12.  Commit 4e7f6e8 makes a lazy fix
> > for that in the master branch; if a more sophisticated solution is not
> > required,
>
> I changed it to a slightly different fix.
>
> The problem was that, on platforms without a cloning BPF device, the BPF device open code iterates over BPF device 
> names, and the loop index was a signed integer, so, in theory, if you have 2^31 BPF devices, from /dev/bpf0 to 
> /dev/bpf2147483647 open, the loop index will go from 2147483647 to -2147483648, and, while 2147483647 requires 10 
> characters, -2147483648 requires 11.  Thus, the length of the buffer had to be increased.
>
> I changed the index to an unsigned integer, so it goes from 0 to 4294967295, all of which require 10 characters.
>
> On most OS versions without a cloning BPF device, you're unlikely to have 2^32 BPF devices (almost certainly not on an 
> ILP32 platform, for obvious reasons!), or even 2^31 BPF devices, so, in practice, this won't be a problem.
>
> The only OS I know of that 1) has no cloning BPF device and 2) auto-creates BPF devices if you try to open one that's 
> past the maximum unit number (it's named after a British naturalist and evolutionist whose last name is not "Huxley" 
> :-)).  It uses "bpf%d" to generate the device names, so it could, in principle, create a device named 
> /dev/bpf-2147483648, but the default upper limit on the number of BPF devices is 256, so you'd have to sysctl it up to 
> a value above 2^31 (the sysctl value is unsigned, so you can do it; that also means that "bpf%d" should be "bpf%u", so 
> it's time to file a Radar^WFeedback on that).
>
> > a simple cherry-pick into libpcap-1.10 should be sufficient
> > to pass CI again.
>
> I've backported a bunch of changes to 1.10, including your change and mine for that; the netbsd-aarch64 build now seems 
> to be working for libpcap-1.10.
>
> (Or should that be netbsd-a64, or netbsd-arm64?  Thanks, Arm, for making "architecture" names so complicated....)
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers