[PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

[Chris Johns]

On 16/3/21 10:00 am, Joel Sherrill wrote:
 On Mon, Mar 15, 2021 at 5:58 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>     On 16/3/21 9:11 am, Gedare Bloom wrote:
>     > On Mon, Mar 15, 2021 at 3:34 PM Alex White <alex.white at oarcorp.com
>     <mailto:alex.white at oarcorp.com>
>     > <mailto:alex.white at oarcorp.com <mailto:alex.white at oarcorp.com>>> wrote:
>     >
>     >     I honestly can't remember why I changed 1024 to 20,000.
>     >
>     >     I've looked back at that code and changed it back to 1024 without any
>     >     issues. I think I might have missed that this is all happening in a loop,
>     >     and at one point during a (long) debugging session I convinced myself that
>     >     it wasn't reading all of the entries.
>     >
>     >     At least that's the most rational explanation I can think up for that
>     >     particular change. 😊
>     >
>     >     If I revert ENTRIES from 20000 back to 1024, are we satisfied to leave the
>     >     "entries" array as-is?
>     >
>     > I think that Chris' main points here are that, as you get covoar working again
>     > and cleaning it up, it should be made more C++ (and less C).
> 
>     Thanks Gedare, yes I am asking if this could be considered. A total conversion
>     is not realistic and would be asking too much but my hope is making changes in
>     small pieces can be done. Some changes will requiring new C++ skills but that
>     should be thought of as a fun challenge.
> 
>     In this case I think changing to a vector would be a good thing for 1024 entries
>     but we had 1024 in the code previously and it was fine so I am also OK if it
>     left that way.
> 
> This is a different case than many of the others, it is reading a block of fixed
> size
> binary entries from the Qemu trace log. It is just avoiding reading the 32-byte
> entries one at a time. It is read, process, and discard. How would
> std::ANYTHING help here?

Nothing or lots, it depends on the code. I did not check this specific case and
reacted to the rather large jump in size that did at one point in the testing
seem important. Once the data is in a container you have a range things std:*
gives you when you use containers, eg find_if with lambda functions. If I was
writing the code in C++ I would have used a container from the beginning and not
a fixed size array with the maintance overhead of sizeof or #defined limits,
this is the the point I am making.

Chris