--- Begin Message ---
On Jul 10, 2022, at 2:48 PM, Denis Ovsienko via tcpdump-workers
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
