Issues with tests about msp HOT 7 CLOSED

Created pull request, still not sure what is wrong with client_read_test

from msp.

Thanks for your contribution.
In the end, I replaced all uint with size_t to be more standard compliant. Can you checkout branch win_build, which contains these changes, and check if it still works for you?

from msp.

branch win_build still works, although client_read_test still blocks.
I'm not very familiar with asio, but I suspect it might because the serial port isn't closed before the Client thread is joined, so asio::read_until(port, buffer, "$M"); never returns.

from msp.

asio::read_until blocks and that is why thread can never join at the end of client_read_test, e.g. after all responses have been received. In client_async_test it is working since the background thread is still sending (and receiving) messages, which unblock asio::read_until.

I pushed an update that detaches from the thread instead of waiting for the result. This should prevent blocking of the program.

from msp.

I don't think detaching the thread is the thing to do, because now fcu_test crashes on exit because the Client thread keeps running even after Client has been destroyed, and tries to access deallocated objects.

from msp.

Thanks for the fixes in PR #12. I am wondering if there are more of these kind of issues (improper deallocation of members at destruction of objects) and if there is a good way of systematically discovering them with tests.

from msp.

I don't have much experience writing robust code, but it is my intuition is that tests won't uncover unexpected edge cases, because they are never thought to test for (the unknown unknowns). I don't have any experience with it, but perhaps a tool like valgrind could help? Another idea might be to add in asserts to expose when basic assumptions are violated?

from msp.