[WhySoBad]

This pull request adds support for non-blocking read/recv and write/send to the UDP socket shim.

This branch is based on the branch from #5497. The ioctl commit can thus be ignored in this PR.

[RalfJung]

Very nice. :)
@rustbot author

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[WhySoBad]

@rustbot ready

[RalfJung]

(comments sent privately as GH is broken)
@rustbot author

[WhySoBad]

The line of the CI failure does not exist anymore? I think the CI should pass when you manually trigger it again.

@rustbot ready

[RalfJung]

I suspect you have to rebase to reproduce the CI failure locally.

[RalfJung]

@rustbot author

View changes since this review

[RalfJung]

I guess we have to map that, this seems too basic to skip.

[WhySoBad]

@rustbot ready

[WhySoBad]

From this connect(3) man page section I'd assume that it should be fine to change the default destination address multiple times (since we can reset a default destination address?):

If the initiating socket is not connection-mode, then connect() shall set the socket's peer address, and no connection is made. For SOCK_DGRAM sockets, the peer address identifies where all datagrams are sent on subsequent send() functions, and limits the remote sender for subsequent recv() functions. If the sa_family member of address is AF_UNSPEC, the socket's peer address shall be reset.

The BSDs seem to interpret this differently. I'd suggest we just store the default destination address on a connect and then always use sendto with either the explicit destination address or the default destination address. If neither is Some we manually return EDESTADDRREQ. We then (again) no longer need the EDESTADDRREQ mapping.

Parsing non-IP socket addresses is one of the things I'll add to my todo list since we currently don't support AF_UNSPEC (and it's also relevant for being able to bind Unix domain sockets).

[RalfJung]

The BSDs seem to interpret this differently.

What do they do instead?
Apparently they return "Socket is already connected". Interesting.

From the spec:

For SOCK_DGRAM sockets, the peer address identifies where all datagrams are sent on subsequent send() functions, and limits the remote sender for subsequent recv() functions.

We'd not emulate this correctly by only storing a default sendto. I guess we can discard packets from different senders ourselves but that's beginning to seem a bit dicey.

POSIX also says

If the socket has not already been bound to a local address, connect() shall bind it to an address which, unless the socket's address family is AF_UNIX, is an unused local address.

So it does not seem unreasonable to say that you can connect at most once.
EDIT: Oh that's the local address, not the remote one.

OTOH it also says

[EISCONN]
    The specified socket is connection-mode and is already connected.

which sounds like for non-connection-mode sockets, double-connecting should work.

Wow that spec is so vague...

[RalfJung]

Honestly my first inclination is to say that we should throw "unsupported" when connect is called the 2nd time. 🤷 I don't think this is common enough to warrant preemptively worrying about it too much.

I also found this in the Rust docs:

If your first connect is to a loopback address, subsequent connects to non-loopback addresses might fail, depending on the platform.

[WhySoBad]

Oh fun, Linux and the BSDs take the different branches of this "or" from the sendto(3) man page:

If a peer address has been pre-specified, either the message shall be sent to the address specified by dest_addr (overriding the pre-specified peer address), or the function shall return -1 and set errno to [EISCONN].

[RalfJung]

@rustbot author

[WhySoBad]

Oh fun, Linux and the BSDs take the different branches of this "or" from the sendto(3) man page:

Do you have a preference on what Miri should do here? Since the POSIX man page explicitly allows either overruling the default destination address or returning EISCONN, I think we should model this as close as possible.

My suggestion would thus be, that for sendto's with an explicit destination address, we return EISCONN on BSD targets if there is already a default destination address set, and on BSD hosts we throw unsupported if there is already a default destination address set.

[RalfJung]

Since the POSIX man page explicitly allows either overruling the default destination address or returning EISCONN, I think we should model this as close as possible.

That sounds reasonable.

[WhySoBad]

@rustbot ready