differences in `struct ifaddrs`

[mwanner]

Currently, there are two variants of struct ifaddrs in libc: one matching Linux with an ifa_ifu field and an OS X variant with only ifa_dstaddr. However, some other BSD derivates define ifa_broadaddr as well, which isn't currently covered (and I guess the fields would be misaligned on systems having ifa_broadaddr as a separate field in the struct).

Googling for getifaddr man pages, I found these different definitions:

Variant 1: union:
http://man7.org/linux/man-pages/man3/getifaddrs.3.html (Linux)
https://docs.oracle.com/cd/E26502_01/html/E29035/getifaddrs-3socket.html (Solaris 11)

Variant 2: only ifa_dstaddr, no ifa_broadaddr (or possibly a macro on ifa_dstaddr):
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/getifaddrs.3.html (OS X)

Variant 3: separate fields ifa_dstraddr and ifa_broadaddr:
http://netbsd.gw.com/cgi-bin/man-cgi?getifaddrs+3+NetBSD-current (NetBSD)
https://www.freebsd.org/cgi/man.cgi?getifaddrs (FreeBSD)
https://man.openbsd.org/getifaddrs.3 (OpenBSD)

Based on these findings, I suppose struct ifaddr in src/unix/bsd/mod.rs would have to move down to the variant-specific fiels under apple, freebsdlike and netbsdlike to adjust for this difference. And the Solaris variant should probably simply be changed to use ifa_ifu. Any other platform that needs to be supported and checked?

[alexcrichton]

Platforms like Solaris and some BSD platforms aren't verified automatically today, so feel free to change the definition on those paltforms!

[marmistrz]

Can Travis test BSD/Solaris?

[alexcrichton]

Only with QEMU currently, they don't offer native hosts running BSD/Solaris

[asomers]

I have a buildbot that I use to test nix and mio-aio on freebsd. What does it take to verify libc? I have plenty of cpu cycles to spare.

[alexcrichton]

Oh note that we've already got QEMU emulation of FreeBSD, is that sufficient for libc?

[asomers]

Yeah, QEMU is probably good enough for libc, as long as its fast enough.

[asomers]

Actually, things aren't as bad as @mwanner thinks. The man pages make it look like the BSDs have an extra ifa_broadaddr field, but it's actually a macro for ifa_dstaddr. AFAICT, the only problem is on NetBSD, which adds an extra ifa_addrflags field at the end.

Here are links to the structure definitions, as opposed to man pages
https://github.com/illumos/illumos-gate/blob/master/usr/src/head/ifaddrs.h
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/include/ifaddrs.h?rev=1.4&content-type=text/x-cvsweb-markup
http://cvsweb.netbsd.org/bsdweb.cgi/src/include/ifaddrs.h?rev=1.8&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
https://svnweb.freebsd.org/base/head/include/ifaddrs.h?revision=250887&view=markup

A maintainer should retitle the issue to "missing field for struct ifaddrs on NetBSD"

[EternalDeiwos]

Registering an interest regarding this for Android.

I've noticed that this seems to be absent from the linux path? Specifically the following in ./unix/bsd/mod.rs:

• L53-61
• L376-L377

seem to be missing from ./unix/nonbsd/mod.rs, which would mean that all linux (not just android) builds of libc would just not have access to libc::ifaddrs?

To further complicate things, if this repo is to be believed, it seems that the Android NDK might not support ifaddrs.

[jakllsch]

The NetBSD situation with ifa_addrflags is complicated. The still-supported NetBSD 7.x release series does not have the ifa_addrflags field, while the NetBSD 8.x release series and -current do.

I've not looked closely as to what this particular difference means for compatibility of binaries. The lack of OS-level ABI/API breaking-change handling in the libc crate leaves a lot to be desired…

[gnzlbg]

It seems that a lot of work has happened here already. What exactly remains to be done here?

[mwanner]

I agree, ifa_broadaddr has vanished, it seems.