I don't really see why this is sufficient validation. We are not checking h_addrtype, so if gethostbyname() isn't returning an IPv4 address, we're just going to copy a bogus value here. If the intent is to guard against a bug in gethostbyname() we should also check for a negative length.

My assumption, based on the gethostbyname(3) man page, was that it only ever returns AF_INET addresses, as opposed to gesthostbyname(2). Looking at the source code, though, it appears not necessarily being the case. I wonder what should we do here - use gesthostbyname2 with AF_INET, or also handle ipv6 addresses? Can getrpcport() callers handle inet6?

Here we're just returning a port number, so I don't see why callers would care which address type is used. The libc code which invokes the GETPORT RPC on the caller's behalf is certainly IPv4 only, but rpcbind knows about IPv6, so it could be fixed without a lot of difficult I think.

For the purpose of this code review, I think using gethostbyname2() as you suggest is fine. The only users of getrpcport() in the base system are the NIS programs, which are IPv4-only I believe.