Fix findUntil and general timeouts in Stream library #2696
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is my proposed fix to issue 2591 #2591 . Primarily this fixes two things: The most important is that searching for something like "1112" in the stream "11112" now works. The second thing is that timeouts on stream reads are properly respected. In the previous version of the code, if you set a timeout of 1000 millisecs and your stream produced a single character every 500 milliseconds, a read would never time out since the clock would be reset every time the program entered timed read. I had to add a handful of private methods to keep all of the other methods intact but I believe that all of the public and protected methods are maintained as before minus the two bugs I described. I also added a low level find routine that would support an arbitrary number of target strings since it's not uncommon to be searching for more than one good string and one error string indistinguishable in the interface from a timeout. This last routine, findMulti() is not very Arduino library like (requiring you to pass in an array of structs) but you need one integer of scratch space per find target* and I felt that dynamically allocating that in the function was a greater sin with only 2k of ram. Everything else uses a constant amount of stack space.