connection: Fix sendmsg() on FreeBSD

It expects ((msg_controllen == 0) == (msg_control == NULL)), and returns
EINVAL otherwise. It can't hurt to be tidy about things on other platforms
either though.

See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=99356#c5

Signed-off-by: Philip Withnall <philip at tecnocode.co.uk>
Signed-off-by: Karsten Otto <ottoka at posteo.de>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
event-loop.c: Use correct OS abstraction function for dupfd()

Signed-off-by: Philip Withnall <philip at tecnocode.co.uk>
Signed-off-by: Karsten Otto <ottoka at posteo.de>
Reviewed-by: David Fort <contact at hardening-consulting.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
wayland-server: Abort if a read from a client gives 0 length

This happens on EOF if using a poll function such as select() or
kqueue() which doesn’t distinguish EOF events.

Currently execution should never reach the point where recvmsg() returns
EOF (len == 0). Instead, epoll() will detect this and indicate EPOLLHUP,
which is handled a few lines above, closing the connection. However,
other event mechanisms may not be able to distinguish EOF from regular
readability (in the case of select()) or inconsistently across platforms
(in the case of POLLHUP). There is also the possibility of half-closed
connections (shutdown(), POLLRDHUP), though this may not be an issue
with Wayland.

This will not cause problems if the FD polls as readable but actually is
not — in that case, recvmsg() will return EAGAIN.

Signed-off-by: Philip Withnall <philip at tecnocode.co.uk>
Signed-off-by: Karsten Otto <ottoka at posteo.de>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
queue-test: Add another assertion

Ensure that the round trip succeeds.

Signed-off-by: Philip Withnall <philip at tecnocode.co.uk>
Signed-off-by: Karsten Otto <ottoka at posteo.de>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>