According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <sys/types.h> when LOCORE is not defined).
From
http://www.isc.org/downloads/libbind/
The libbind functions have been separated from the BIND suite as of BIND
9.6.0. Originally from older versions of BIND, they have been continually
maintained and improved but not installed by default with BIND 9. This
standard resolver library contains the same historical functions and
headers included with many Unix operating systems. In fact, most
implementations are based on the same original code.
At present, NetBSD maintains libbind code, now known as "netresolv".
The resolver in libc creates a kqueue for watching a single file descriptor.
This can be done using poll() which should be lighter on the kernel and
reduce possible problems with rlimits (file descriptors, kqueues).
Reviewed by: jhb
warn about it. I guess this was originally done to silence a bogus
warning by an older version of gcc, but I could not reproduce it with
any version of gcc that I have access to.
MFC after: 1 week
It includes the following fix:
2426. [bug] libbind: inet_net_pton() can sometimes return the
wrong value if excessively large netmasks are
supplied. [RT #18512]
Reported by: Maksymilian Arciemowicz <cxib__at__securityreason.com>
poll(2) or kqueue(2). Previously we rejected fd's higher than FD_SETSIZE
for kevent(2), and larger than sysconf(_SC_OPEN_MAX) for poll(2). However,
the check for poll(2) wasn't really needed. open(2) and socket(2) won't
return an fd you can't pass to either poll(2) or kevent(2). This fixes
a but where gethostbyname() would fail if you had more than 1023 files
open in a process.
MFC after: 1 week
Reviewed by: ume
Found by: ps
following fix:
Retransmission timeouts should be based on which attempt
it is to the nameserver and not the nameserver itself.
Obtained from: ISC
MFC after: 3 days
old resolver opened just one socket, BIND9's resolver may
open more than one sockets. And, BIND9's resolver doesn't
close the socket on timeout. So, we need this check.
Reported by: freebsd-cvs-src__at__oldach.net (Helge Oldach), bz
Hinted by: rwatson
