|
Bugzilla – Full Text Bug Listing |
| Summary: | TcpSocketImpl::Recv returns 0 without setting m_errno | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Mathieu Lacage <mathieu.lacage> |
| Component: | internet | Assignee: | Rajib Bhattacharjea <raj.b> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | craigdo, gjcarneiro, ns-bugs, raj.b |
| Priority: | P1 | ||
| Version: | pre-release | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
untested fix
tested fix |
||
|
Description
Mathieu Lacage
2008-09-23 16:51:19 EDT
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 |