[Issue 24404] if_dstaddr field in ifaddrs should be ifu_dstaddr on Linux

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Feb 23 07:39:37 UTC 2024


https://issues.dlang.org/show_bug.cgi?id=24404

--- Comment #1 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
Actually, the situation is a bit more nuanced, though druntime still has the
name wrong.

```
struct ifaddrs {
               struct ifaddrs  *ifa_next;    /* Next item in list */
               char            *ifa_name;    /* Name of interface */
               unsigned int     ifa_flags;   /* Flags from SIOCGIFFLAGS */
               struct sockaddr *ifa_addr;    /* Address of interface */
               struct sockaddr *ifa_netmask; /* Netmask of interface */
               union {
                   struct sockaddr *ifu_broadaddr;
                                    /* Broadcast address of interface */
                   struct sockaddr *ifu_dstaddr;
                                    /* Point-to-point destination address */
               } ifa_ifu;
           #define              ifa_broadaddr ifa_ifu.ifu_broadaddr
           #define              ifa_dstaddr   ifa_ifu.ifu_dstaddr
               void            *ifa_data;    /* Address-specific data */
           };
```

The union's field is suppposed to be ifu_dstaddr rather than if_dstaddr, though
you would have to access it through the union to use that name. The #defined
names - ifa_broadaddr and ifa_dstaddr - match what other POSIX platforms use,
and I'm not sure that it's actually intended that anyone would use the ifu_*
names via the union.

So, the correct fix here would either be to make it so that druntime names the
union and provides function wrappers (since we can't use aliases to access the
ifa_ifu's members) so that it's both possible to access the ifu_* names via the
union name and possible to use the ifa_* names - OR we should just use the
ifa_* names. I'm inclined to go with the second, since it doesn't require
helper functions and matches what other platforms have.

--


More information about the Digitalmars-d-bugs mailing list