some applications use getservbyport to find port numbers that are not
assigned to a service; if getservbyport always succeeds with a numeric
string as the result, they fail to find any available ports.
POSIX doesn't seem to mandate the behavior one way or another. it
specifies an abstract service database, which an implementation could
define to include numeric port strings, but it makes more sense to
align behavior with traditional implementations.
based on patch by A. Wilcox. the original patch only changed
getservbyport[_r]. to maintain a consistent view of the "service
database", I have also modified getservbyname[_r] to exclude numeric
port strings.
this is a clone of the fix to the gethostby*_r functions in
commit fe82bb9b92. the man pages
document that the getservby*_r functions set this pointer to
NULL if there was an error or if no record was found.
all socket types are accepted at this point, but that may be changed
at a later time if the behavior is not meaningful for other types. as
before, omitting type (a value of 0) gives both UDP and TCP results,
and SOCK_DGRAM or SOCK_STREAM restricts to UDP or TCP, respectively.
for other socket types, the service name argument is required to be a
null pointer, and the protocol number provided by the caller is used.
now that host and service lookup have been separated in the backend,
there's no need for service lookup functions to pull in the host
lookup code. moreover, dynamic allocation is no longer needed, so this
function should now be async-signal-safe. it's also significantly
smaller.
one change in getservbyname is also made: knowing that getservbyname_r
needs only two character pointers in the caller-provided buffer, some
wasted bss can be avoided.
Rich Felker
Daniel Sabogal