Bruno Haible <[EMAIL PROTECTED]> writes: >> One idea would be a gnulib module to implement a replacement >> getservbyname function that supports all the IANA registered names, or >> at least also supports https. > > Why only https then? I would use a reasonably complete list, and precompile > it using gperf (to speed up the search).
Some reasons: 1) Supporting a complete list takes up a lot of size. Not all projects use non-numeric service fields in getaddrinfo, so it can be wasteful. 2) Hard coding the service <-> port mappings breaks the ability to modify port numbers by editing /etc/services or using NIS or whatever. I'm not sure if there is ever a valid reason to modify port numbers this way, but I think it will be surprising if we break this old tradition. 3) Detecting whether the system's internal getaddrinfo has failed only because of an unsupported service may be trickier. Based on your work, we now know that 'https' fail in a specific way even though 'http' for the same name works, on two specific systems. We could add a wrapper to, on these error codes and for these systems, re-try any failed call for "https" with a call for "443", to see if that succeeds. If we re-try (failed) queries for, say 'http', too, we may introduce surprising behavior: consider if the system maps 'http' to port 8080, and that lookup fails because no such service is registered [1], and we re-try it using port 80 instead, which could succeed. None of these are particular strong reasons, or perhaps even valid reason, but to me they are together good reasons to make any behavior like this optional. /Simon [1] I'm assuming here that getaddrinfo uses NIS (or possibly something like SRV records) so that lookups can fail because there is no service on that address, even though the address itself is valid.
