-
-
Notifications
You must be signed in to change notification settings - Fork 608
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The names of the union fields in Linux's ifaddrs are named incorrectly. #17474
Labels
Comments
issues.dlang (@jmdavis) commented on 2024-02-23T07:39:37ZActually, 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. |
dlang-bot commented on 2024-02-23T07:53:35Z@jmdavis created dlang/dmd pull request #16233 "Fix Bugzilla issue 24404 - ifaddrs union fields incorrectly name on Linux." fixing this issue:
- Fix Bugzilla issue 24404 - ifaddrs union fields incorrectly name on Linux.
You can see the correct declaration for ifaddrs on Linux here:
https://www.man7.org/linux/man-pages/man3/getifaddrs.3.html
What the fields are supposed to be named is ifa_broadaddr and
ifa_dstaddr. However, because Linux defines them using a union, it gives
them different names within the union - ifu_broadaddr and ifu_dstaddr -
and then #defines the proper names to access the union names.
What druntime did was use the union names - and then incorrectly name
ifu_dtsaddr as if_dstaddr. So, it was doubly wrong for that field.
The two approaches that we could take here would be to either
1. Turn the union into a type so that we could have an ifa_ifu field to
allow accessing the ifu_* names that way - as is technically possible
in C - and then add wrapper functions with the ifa_* names (since we
couldn't use an alias to access members of the union member
variable).
2. Just rename the fields to ifa_* and ignore the fact that you can
technically access the ifu_* fields via the union name in C.
The simpler approach is #2, so that's what this commit does. I'm pretty
sure that the ability to access the ifu_* fields via the union name is
just an implementation detail - particularly since other platforms just
declare the ifa_* names without using a union at all.
Either way, deprecated aliases are provided so that existing code
doesn't break.
https://github.com/dlang/dmd/pull/16233 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jonathan M Davis (@jmdavis) reported this on 2024-02-23T07:01:27Z
Transferred from https://issues.dlang.org/show_bug.cgi?id=24404
Description
core.sys.linux.ifaddrs's ifaddrs struct incorrectly names the ifu_dstaddr field if_dstaddr. https://www.man7.org/linux/man-pages/man3/getifaddrs.3.html
The text was updated successfully, but these errors were encountered: