@faern noted this in https://internals.rust-lang.org/t/why-are-socketaddrv4-socketaddrv6-based-on-low-level-sockaddr-in-6/13321
|
SocketAddr::V4(ref addr) => ( |
|
addr as *const _ as *const libc::sockaddr, |
|
size_of_val(addr) as libc::socklen_t, |
|
), |
|
SocketAddr::V6(ref addr) => ( |
|
addr as *const _ as *const libc::sockaddr, |
|
size_of_val(addr) as libc::socklen_t, |
|
), |
As far as I can tell there are no guarantees from std about the layout of SocketAddrV{4,6}, and this code could silently compile and cause UB elsewhere if the representation changes (e.g. if padding is added early on in the struct, resulting in C code reading uninitialized bytes).
@faern noted this in https://internals.rust-lang.org/t/why-are-socketaddrv4-socketaddrv6-based-on-low-level-sockaddr-in-6/13321
mio/src/sys/unix/net.rs
Lines 78 to 85 in 27fbd5f
As far as I can tell there are no guarantees from
stdabout the layout ofSocketAddrV{4,6}, and this code could silently compile and cause UB elsewhere if the representation changes (e.g. if padding is added early on in the struct, resulting in C code reading uninitialized bytes).