Guy Harris

> `pcap_nametonetaddr()` uses three different implementations of `getnetbyname_r()` That's because there's no standard for `getnetbyname_r()` - it's not in POSIX, as of the latest issue, Issue 8 - so GNU...

> Thank you for testing. Do you mean macOS and FreeBSD work the same and both return 0x007f0001? Unfortunately, they don't. It appears that macOS 13.6.9, at least, seems to...

> In GNU libc `nss_files/files-network.c` says: Oh, *that's* where they hid the "files" module's getnetent code!

> Old-style network classes may be a factor. They may be, but that's not an excuse for Darwin - 192.0.1.x would be a class *C* network, so the network number...

> Time to dig into libinfo source, I guess. Darwin uses `atoi()` on the second token in /etc/networks lines. This is a bug, given that the networks(5) man page on...

Feedback submitted.

So, at least at present: - using an /etc/networks network name with "net" on Linux with GNU libc produces a bogus filter; - using an /etc/networks network name with "net"...

> Another useful starting point could be identifying OSes that do it right, at least in some cases if not always, and adding tests for those patches of correct behaviour....

Also, if the "network number" of a network is defined to be "if you take the IPv4 address of any host on the network, AND it with the net mask,...

Tested on: - FreeBSD 14.1-RELEASE - works as expected; - DragonFly 6.4-RELEASE - works as expected; - NetBSD 9.4 - works as expected; - OpenBSD 7.5 - doesn't use /etc/networks,...