Can't move to 0.6 due to `SockAddrStorage` vs. `libc::sockaddr_storage` limitations

[shaun-cox]

I'm trying to adapt to the breaking change from 0.5.10 to 0.6, but don't see a way for my use cases of socket2::SockAddr::new which now takes a SockAddrStorage instead of the previous libc::sockaddr_storage. Also, the latter is Copy and Clone, while the former is not. I cannot construct a SockAddrStorage from a libc::sockaddr_storage that I obtain from a syscall like recvmmsg either, so it seems I'm stuck.

[Thomasdezeeuw]

You can do the following:

let mut address = socket2::SockAddrStorage::zeroed();
let mut libc_address = unsafe { address.view_as::<libc:: sockaddr_storage>() }; // or sockaddr_in etc.
*libc_address = recv_address; // recv_address from recvmmsg.
SockAddr::new(address, size_of::<libc:: sockaddr_storage>());

We should probably implement Copy and Clone for SockAddrStorage though if that makes the API easier to use.

I would also like to implement an easier conversion from libc's storage addresses to socket's version, however having libc in the stable API is a problem if get updated from v0.2 to v1. Libc (the crate) has been very stable, but the windows equivalent hasn't since it's already up to v0.60, see #526 for some more background on this.

[Darksonn]

We should probably add an example like this to the docs. @shaun-cox Do you want to submit one?

[shaun-cox]

Thank you for the quick responses. (I'll work on an example for the docs in the coming days spare time.)

[Thomasdezeeuw]

I'm going to close this as I don't think this is an issue any more.