esp8266 _oob_* : recv() brought back where it was needed

[dmaziec]

Description

As reported in: #11537 in esp8266::_oob_* recv() is brought back where scanf() fails.
scanf() immediately returns after finding one digit of the number, while recv() matches the whole number.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@ccli8
@michalpasztamobica
@0xc0170

Release Notes

[ciarmcom]

@dmaziec1, thank you for your changes.
@michalpasztamobica @0xc0170 @ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

[michalpasztamobica]

@VeijoPesonen , your feedback, as usually, will be appreciated :)

[ccli8]

Verify OK on #11537

[VeijoPesonen]

Looks ok but could you also add a comment to ATCmdParser.hpp about scanf and its limitations. The fact that it won't consider whitespace as part of the string it tries to match. Information source, @kjbracey-arm . An issue should also be created that there is a need to combine scanf's and recv's implementations in a way that scanf is just the one which gives up immeadiatelly after it doesn't find a match. Then it would also work as expected in a case like this where there are multiple digits at the end of a line.

[michalpasztamobica]

@VeijoPesonen , regarding the comment that you would like us to add... do you mean something like this, but moved to the doxygen header's documentation?

Could you please clarify a bit further on what the bug report should aim at? vrecv and vscanf work in a similar manner. To my understanding the difference currently is that you can request a "whole line" in vrecv, while vscanf will not handle this (just as scanf doesn't). To me it seems neither of them will be able to handle a multiple character number, unless the format string ends with a new line (no other white space will do) and vrecv was used.

[VeijoPesonen]

do you mean something like this, but moved to the doxygen header's documentation?

Yes, that should work.

Could you please clarify a bit further on what the bug report should aim at? vrecv and vscanf work in a similar manner. To my understanding the difference currently is that you can request a "whole line" in vrecv, while vscanf will not handle this (just as scanf doesn't). To me it seems neither of them will be able to handle a multiple character number, unless the format string ends with a new line (no other white space will do) and vrecv was used.

vrecv and vscanf should be merged together. The goal is to give a configuration parameter for this function which would indicate are we trying to find a match from one line(scanf) or do we might end up processing multiple lines(recv) to find a match.

[VeijoPesonen]

Please fix indentation. I would say that ESP8266 and ATCmdParser changes should be done on separate commits.

[michalpasztamobica]

A separate PR was created (and approved) for documentation update.
An internal JIRA was created to track the possible merge of recv and scanf, as described by Veijo.
I guess this is pretty much ready for merge.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts