Fix WiFiClientSecure read() and available() logic to properly include peeked byte #2151
Conversation
…re is still data in the buffer. Otherwise, how would we know it was there?
…logic to include correctly include peeked byte in available count
| } | ||
| buf++; | ||
| peeked = 1; | ||
| int ret = read(buf+1, size-1); |
There was a problem hiding this comment.
I fail to see what this fixes? Also calling a function on itself? Why? Note that size has already been subtracted. Every time there is a peek byte, you will get 1 byte less.
There was a problem hiding this comment.
Ah yes, the double subtraction was my mistake. I pushed a commit to fix that. The changes to read(...) and the recursive function call just clean up and remove a bunch of redundant code.
What's really meant to be fixed is available(). Here it has the same problem WiFiClient had, where if not connected it would return 0, even if there was data available. Another problem was, if the data_to_read result res was less than 0, it would just return that negative value, even if there is a peeked byte available.
There was a problem hiding this comment.
Actually there was a problem in read(...) too, where if you have a peeked byte, but then res is a negative number, you just return the negative, whereas it should be returning 1 to indicate you read the peeked byte at the very least.
There was a problem hiding this comment.
Still I would rather you revert this recursive call and fix the "returns -1 if read failed but there was a peek" when get_ssl_receive returns negative.
|
Please add descriptions to you pull requests. What they do, what they fix, and so on. |
|
Please rebase :) there is a duplicate change for WiFiClient. Also note this PR: #2155 |
No description provided.