On Mon, Mar 15, 2021 at 5:58 PM Chris Johns <chr...@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.wh...@oarcorp.com > > <mailto:alex.wh...@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? --joel > > Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
