oh, ha. So this is what allows struct sockaddr casting not to be UB...
-
-
Replying to @damienmiller
That's different and it is UB if you use sockaddr.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
how? if you check af_family and only used subsequent fields for same type, then this seems to fall under initial member rules
1 reply 0 retweets 1 like -
Replying to @damienmiller
(*(struct sockaddr *)sin).sa_family is not the same as *(sa_family_t *)sa. Latter is well-defined C but assumes sa_family is first member.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @damienmiller
The former is an aliasing violation because it accesses the object pointed to by sin with the wrong type, struct sockaddr.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
ah, but accessing the family directly as (sa_family_t*)sockaddr would be okay I guess.
1 reply 0 retweets 0 likes -
Replying to @damienmiller
Yes, but I don't think POSIX imposes a requirement that sa_family be the first member...
1 reply 0 retweets 1 like -
Replying to @RichFelker @damienmiller
You could do *(sa_family_t*)((char *)p+offsetof(struct sockaddr, sa_family)) :-)
1 reply 0 retweets 0 likes -
Replying to @RichFelker @damienmiller
The right solution is treating "struct sockaddr *" as an abstract/opaque type and using it just with getaddrinfo/getnameinfo/bind/connect.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
That's not an option if you need to e.g. extract a port number from a sockaddr or manipulate/compare an address sadly.
1 reply 0 retweets 0 likes
Sure it is. getnameinfo (use NI_NUMERICHOST|NI_NUMERICSERV) converts them to string forms you can manipulate and match.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.