Even when C89 was being drafted, there was a concern for ensuring that compilers could optimize based on non-aliasing assumptions.
Well they are on some level. I just found it ridiculous that OpenBSD is nonchalauntly saying their code needs -fno-strict-aliasing
-
-
..rather than fixing their UB like I'd expect from a secure OS, & just using -fno-strict-aliasing as extra hardening/safety.
-
in other thread I pointed out an example of how the sockets API demands no-strict-aliasing (not just OpenBSD either)
-
And I've pointed out in multiple threads how that claim is wrong and it's only bad legacy socket code that has probs
-
about that, I'm not sure how “treat the structs as opaque” helps the OS implementers that have to provide the functions.
-
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.
-
musl's getaddrinfo looks clean/correct here: https://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c?h=v1.1.15#n64 …
-
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 …
-
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 …
- 2 more replies
New conversation -
-
-
they include expat. That alone makes them right about their choice. And it's only the first legacy library we have looked at!
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.