Well, if you’re going to replace a library as large as glibc, you have to start somewhere. And why not getaddrinfo?
I’ll definitely be paying attention to any progress. I also wonder if this work will prove valuable to the ‘main’ libc implementations, and adopt some amount of rust code into their respective codebases. e.g. What if parts of musl or glibc were written in Rust?
It’s interesting that Go actually can use a resolver written in pure go avoiding getaddrinfo on unix systems
On Unix systems, the resolver has two options for resolving names.
It can use a pure Go resolver that sends DNS requests directly to the servers
listed in /etc/resolv.conf, or it can use a cgo-based resolver that calls C
library routines such as getaddrinfo and getnameinfo.
Go doesn’t usually use a libc at all, let alone getaddrinfo. (Yes, cgo can, but http://dave.cheney.net/2016/01/18/cgo-is-not-go )
Feels like a redux of what has historically been a frustrating property of the Java Runtime Enviroment. That is: many Java-specific versions of things like DNS configuration, the certificate store, the timezone database. Sure, it makes things more uniform across different platforms, but i actually want to use the features of my OS.
Does this mean that Java isn’t affected by the latest glibc dns bug?