--- Begin Message ---
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

Reply via email to