Well they are on some level. I just found it ridiculous that OpenBSD is nonchalauntly saying their code needs -fno-strict-aliasing
-
-
Replying to @RichFelker
..rather than fixing their UB like I'd expect from a secure OS, & just using -fno-strict-aliasing as extra hardening/safety.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
in other thread I pointed out an example of how the sockets API demands no-strict-aliasing (not just OpenBSD either)
1 reply 0 retweets 0 likes -
Replying to @damienmiller
And I've pointed out in multiple threads how that claim is wrong and it's only bad legacy socket code that has probs
1 reply 0 retweets 0 likes -
Replying to @RichFelker
about that, I'm not sure how “treat the structs as opaque” helps the OS implementers that have to provide the functions.
2 replies 0 retweets 0 likes -
Replying to @volatile_void
Then let's analyze what's wrong here in musl, if anything, and fix it if so. That should shed light on whether there's an issue.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
musl's getaddrinfo looks clean/correct here: https://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c?h=v1.1.15#n64 …
1 reply 0 retweets 0 likes -
Replying to @RichFelker
musl's getnameinfo probably has one minor sockaddr aliasing error: https://git.musl-libc.org/cgit/musl/tree/src/network/getnameinfo.c?h=v1.1.15#n131 …
1 reply 0 retweets 0 likes -
Replying to @RichFelker
res_msend may have a tiny issue if bind() were 3rd-party, but since it's ours and just a syscall, it's ok: https://git.musl-libc.org/cgit/musl/tree/src/network/res_msend.c?h=v1.1.15#n71 …
1 reply 0 retweets 0 likes -
Replying to @RichFelker
And finally getifaddrs may have some sockaddr aliasing issues; I'm not familiar enough with that code to judge immediately.
1 reply 0 retweets 0 likes
Everything else in musl looks clean with respect to struct sockaddr.
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.