Go’s standard lib has quite a rich set of APIs in this area: https://golang.org/pkg/net/#Interface which are obviously cross platform.
In fact I was thinking of modelling the code in my own crate, which I’m planning to write, after Go’s API surface.
Edit: Unfortunately Go makes the choice earlier on in the retrieval process to push everything into a vector and then return the vector which I was hoping to avoid in Rust. The core problem is that the structure of data returned by Linux and Windows is quite different. Ensuring a common return structure will necessitate one of the OSes having to suffer some extra processing or allocation. Windows returns the information already arranged interface-wise while Linux (or libc) returns it in terms of individual addresses. From an ergonomic perspective I like “Interface” as a unit of packaging. So I feel it’s Linux that’ll have to suffer some perf penalty in order to have it’s data transformed into Interface objects. What we can do is expose an additional “Ext” trait which will also expose the zero-cost access to
getifaddrs in case someone wants to directly use that.
Further edit: Well, upon further reading of Go’s code it doesn’t seem to be using
getifaddr for linux at all. It appears to use some netlink APIs which do return information arranged interface-wise quite like Windows. So there’s probably no need to reconcile between different structures. But Go is still putting everything in vectors. I think Rust can easily return iterators in this case and thus avoid perf costs mentioned above.