-
Notifications
You must be signed in to change notification settings - Fork 2k
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
sys/net/sock: provide ipv{4, 6}_addr_t in union #18617
base: master
Are you sure you want to change the base?
Conversation
Can we consider the members of some If so, IMO we could just drop all other members of the union and only keep If not, I suggest to mark all other members of the |
Certainly not, it's not uncommon to statically initialize a e.g. |
3be7b73
to
51b25a7
Compare
But then still, deprecating the others sounds like a good thing to do at this point. (Currently that'd just be through documentation; #18565 is still blocked on doxygen issues). |
I think @kaspar030 has his opinion on this. ;-) |
The reason why we did not include |
IMO, keeping it that way also keeps it a bit sane. The address types in |
I see that point about sock being standalone (and ad "what other than RIOT": a portable application can take RIOT's sock API and implement it on the other platforms it wants to be portable to). But maybe we can treat things the other way, move the address types into socket (say, |
That argument is pretty odd, on the one hand we have a |
I'd prefer having a type that does the type punning right once-and-for-all (with type names indicating that this is not a machine-encoded uint32_t but a 32-bit integer encoded in network byte order, if treating an IP address as a 32bit int ever makes sense in any than opaque aligned-4-byte-blob form) than having places like this where again an IP address is split up into its different possible representations. |
I agree that typedef union {
uint8_t u8[16];
union __attribute__((packed)) {
uint16_t u16;
uint8_t u8[2];
} u16[8];
union __attribute__((packed)) {
uint32_t u32;
uint8_t u8[4];
uint16_t u16[2];
union __attribute__((packed)) {
uint16_t u16;
uint8_t u8[2];
} b16[2];
} u32[4];
union __attribute__((packed)) {
uint64_t u64;
uint8_t u8[8];
uint16_t u16[4];
uint32_t u32[2];
union __attribute__((packed)) {
uint16_t u16;
uint8_t u8[2];
} b16[4];
union __attribute__((packed)) {
uint32_t u32;
uint8_t u8[4];
uint16_t u16[2];
union __attribute__((packed)) {
uint16_t u16;
uint8_t u8[2];
} b16[2];
} b32[2];
} u64[2];
} ipv6_addr_t; But rather than running away from it screaming (which also is my first instinct), we should just fix it. And then we can actually use it. |
If we would have CI time stats, we could actually track down how much CI time it will shave of to fix |
So,
?
|
this is how it looks in linux:
|
Addresses are lugged around often enough that alignment can make sense (but that can be done with But I don't want to slow this down by arguing about alignment: Both an aligned and an unaligned simple |
Contribution description
This allows to statically initialize a e.g.
sock_udp_ep_t
with a prefix and IID.Testing procedure
works now
Issues/PRs references