same for NscTcpSocketImpl::Recv

as florian pointed out, that whole API is problematic for EOF. 0 is a valid return value which does not indicate error so, we can't use it to indicate error.

options:
  - add ERROR_EOF
  - return -1 
  - change the Ptr<Packet> return value to int

all are pretty ugly :/

another option to represent EOF would be to return a zero-sized packet. That is not less ugly than the other options.

How about returning a NULL "pointer" (Ptr<Packet> ()) on error?

Ptr<Packet> p = socket->Recv ();
if (!p)
{
  // check socket->GetErrno ();
}

(In reply to comment #4)
> How about returning a NULL "pointer" (Ptr<Packet> ()) on error?
> 
> Ptr<Packet> p = socket->Recv ();
> if (!p)
> {
>   // check socket->GetErrno ();
> }


yes, we already do this. The question is: how do you handle EOF ?

As an update, the last thing we agreed on during the last IRC chat was:
 - Recv returns the pointer 0 if the connection is still open, but there is no data to read
 - Recv returns a pointer to an empty Packet if there is no data to read and the connection has closed (the EOF case)

Created attachment 291 [details]
untested fix

Created attachment 333 [details]
tested fix

changeset
4014:b6349d9c007e