getaddrinfo is defined by POSIX and UNIX. Where the implementation is doesn’t matter. It’s portable, which is why it’s used. The slide deck referenced above talks about better implementations for various platforms, but they are all platform specific.
So OP might not be completely accurate, but getaddrinfo is _the_ way to resolve names if you are writing portable POSIX and/or UNIX code.
Not nitpicking at all. I just don't like how people see Linux as a "POSIX implementation". It's much more than that.
Practical compatibility is not compliance, the manuals document many subtle differences and incompatibilities. The practicality of it mostly comes from glibc which everyone uses and which does strive to be compliant. Even then it's a hit and miss, the so called "Linuxisms" crop up in the most unexpected of places. The executable path that people write in the shebang lines of their shell scripts, for example. It's gotten to the point some BSDs have started emulating Linux system calls instead of porting software. Even Windows did this once upon a time.
My point is glibc is not even guaranteed to exist on the system. POSIX is not at all mandatory on Linux. The POSIX interfaces are just one of the ways to interface with the kernel. It's also possible to bypass all the POSIX stuff and interface with it directly. Linux is the only operating system to offer this ability via the stable kernel-userspace binary interface. It's even defined at the instruction set level which makes it programming language agnostic. On Linux you actually can trash all that POSIX stuff and reinvent it all in Rust if you want.
> Linux and the popular Linux distributions are not POSIX compliant to begin with.
While not (entirely) wrong, not entirely correct either.
Good luck trying to compile and run any kind of software without providing getaddrinfo(), socket(), connect(), etc to userland:
* https://pubs.opengroup.org/onlinepubs/9699969599/functions/g...
> Good luck trying to compile and run any kind of software without providing getaddrinfo(), socket(), connect(), etc
I'm working on a freestanding lisp language with built in Linux system call support at least in part because I want to to prove that this sort of thing is possible. No legacy interfaces will be provided and yet I have no doubt in my mind that one day it will be able to everything you mentioned and much more.
Your comment above was that it is a glibc function, which is true, but it’s there for reason. It’s also a libc, musl, uClibc, and Windows Sockets 2 function: because it’s defined in POSIX 1.1 and extended in RFC 3493.
I have no opinion on whether it’s good enough (it seems like not if every platform has a connect-by-name implementation), just that calling it a glibc function overly simplifies it’s origin.
It’s also false to say only GNU tries to be POSIX compliant. There are 8 commercial UNIXes that meet some POSIX standard, another 8 that are discontinued (at least one of which was a Linux distro), and dozens that are mostly compatible. POSIX doesn’t care if that compatibility comes from the kernel or user space libraries.
POSIX isn’t good enough at what? Maybe you don’t understand what it’s goal is/was. POSIX exists for portability. It’s a minimal set of functions developers can target to get things done on any UNIX. Any OS will always have something beyond POSIX to differentiate it.
The point I tried to make is the getaddrinfo function is not sacred. It's not the way to do anything at all on Linux. It's just the function that glibc has, and most people use it. Whether it came from POSIX or something else seems like a minor detail to me. POSIX and glibc are not sacred either.
> Any OS will always have something beyond POSIX to differentiate it.
Linux is no exception. We should all be enjoying those exclusive features to their fullest extent. Not restricting ourselves to the lowest common denominator between them. Portability is a trap.
Linux and the popular Linux distributions are not POSIX compliant to begin with. Only GNU tries to be, and even GNU adds on a ludicrous amount of extensions because the truth is POSIX isn't good enough.