Good catch! I seem to have overlooked that while adding these functions. It is possible to use PacketBuffer::dequeue_with to return an error in this case (probably Error::Truncated).

What we should do in this case is an interesting question. The recv_slice methods are, essentially, convenience methods, so any limitations they have do not fundamentally alter the capabilities of the socket. If recv_slice returns an error and does not dequeue, then the caller must handle that case to avoid getting stuck in a receive loop and use recv to dequeue the overlong packet. But that seems to defeat the purpose of using recv_slice.

Therefore I argue that it should return an error (probably Error::Truncated) and dequeue the overlong packet, since that's what the caller will have to do in any case where it can use recv_slice . In any other case recv should be used rather than recv_slice.

I this still an issue?

cc @Dirbaio

Fixed by #859.