How can sf::Packet fail?

[Nexus]

The sf::Packet operators << and >> return a reference to the packet and thus allow to test it for validity. Assume that the socket's receive() function is tested for sf::Socket::Done, therefore the transmission itself is successful.

For the sf::Packet::operator>>, are logic errors (bugs) the only way it can fail -- when received data is not interpreted the way it has been sent? So we don't need to check the packet in a correctly-written program?

And in which cases can sf::Packet::operator<< fail?

Are there any differences with respect to sf::Packet validity for TCP and UDP? To which extent can UDP datagrams be corrupted at the level of SFML? Again, we assume that receive() returned sf::Socket::Done.

[Laurent]

So many questions

For the sf::Packet::operator>>, are logic errors (bugs) the only way it can fail -- when received data is not interpreted the way it has been sent? So we don't need to check the packet in a correctly-written program?

operator >> can fail only if you try to read more than what the packet contains.

So we don't need to check the packet in a correctly-written program?

Right.

And in which cases can sf::Packet::operator<< fail?

It cannot fail (unless you are out of memory, which throws a std::bad_alloc exception).

Are there any differences with respect to sf::Packet validity for TCP and UDP?

No, sf::Packet knows nothing about UDP/TCP, so once the data is successfully received and put in a packet, everything's the same.

To which extent can UDP datagrams be corrupted at the level of SFML?

UDP datagrams can never be corrupted. They can only be lost, duplicated or reordered.

By the way, I didn't remember and I had to check the source code to answer your first questions; it's so simple that you could have done it directly

[Nexus]

Hehe, sorry. I took a look at the API documentation, and unfortunately, it tells very few about possible errors. I suggest to mention how sf::Packet::operator>> can fail and in which situations it's meaningful to check it. I can imagine that even a correct program might read until it arrives at the end of the packet (as an alternative to checking the packet size) -- for example, if the packet contains just a dynamic sequence of elements.

I also wondered why the socket's send() functions take a non-const reference to the packet (sf::Packet&). Here I did look in the source code, the reason seems to be the virtual onSend() and onReceive() methods that may modify the object.

Anyway, thanks a lot for the answers!