Guus Sliepen <g...@debian.org> writes:
> Hm, I did not expect that, but according to codesearch.debian.net you
> are right. I'm actually stunned by the amount of programs that do
> something like:
> struct protoent *pe = getprotobyname("TCP");
> int s = socket(AF_INET, SOCK_STREAM, pe->p_proto);
> ...when there is the perfectly fine IPPROTO_TCP. Every time
> getprotobyname() or getservbyname() is called, glibc opens
> /etc/protocols or /etc/services and parses the whole file. What a waste:
> it takes more effort to program it like this, it wastes CPU cycles and
> disk IO, and it has more potential to fail.
While I agree with you that getprotobyname is probably pointless, I don't
really agree for getservbyname (or getaddrinfo, which is the more modern
way to do this). Those don't have well-defined constants, and while the
ability to change that file and thus change software behavior is of very
limited use, I do think it makes for more readable code to use symbolic
service names. A minor point, and it doesn't make a huge difference in
the long run, but it's what I do in my software and I think it has some
clear merits.
I don't really buy the performance argument for nearly all software.
Reading a file from disk isn't very slow, and for *most* software this
isn't a hugely frequent operation. (There are certainly cases where it
would be an issue, but in most of those cases it's already a better idea
to cache the results of getaddrinfo for some time.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
