Fixed severe bug in PSOCK_READTO (?)

Either I found and fixed a severe bug in PSOCK_READTO() or I misunderstood something completely. To me PSOCK_READTO() is supposed to return if either the supplied character was read or if the user supplied buffer is exhausted - sor far so good.

However if the latter occurs up to now PSOCK_READTO() was continuing to process characters already read from the network (aka present in the uIP buffer) in order to check if the supplied character was found there and adjust the return value accordingly. But this means that the character processed this way were lost forever for the caller as the next call to PSOCK_READTO() would continue to read past the characters processed this way.

Therefore I removed that character processing altogether. So now if the user supplied buffer is exhausted before the supplied character is found the next call to PSOCK_READTO() starts exactly where previous call left off.
ico
Oliver Schmidt 2013-02-09 22:22:31 +01:00
parent 19c8f9ffdd
commit 1eda821a75
1 changed files with 3 additions and 13 deletions

View File

@ -124,16 +124,6 @@ buf_bufto(CC_REGISTER_ARG struct psock_buf *buf, uint8_t endmarker,
return BUF_NOT_FOUND;
}
while(*datalen > 0) {
c = **dataptr;
--*datalen;
++*dataptr;
if(c == endmarker) {
return BUF_FOUND | BUF_FULL;
}
}
return BUF_FULL;
}
/*---------------------------------------------------------------------------*/
@ -274,9 +264,9 @@ PT_THREAD(psock_readto(CC_REGISTER_ARG struct psock *psock, unsigned char c))
psock->readptr = (uint8_t *)uip_appdata;
psock->readlen = uip_datalen();
}
} while((buf_bufto(&psock->buf, c,
&psock->readptr,
&psock->readlen) & BUF_FOUND) == 0);
} while(buf_bufto(&psock->buf, c,
&psock->readptr,
&psock->readlen) == BUF_NOT_FOUND);
if(psock_datalen(psock) == 0) {
psock->state = STATE_NONE;