Actions
Bug #9401
closedMemory editor reads last memory twice
Start date:
09/28/2021
Due date:
% Done:
100%
Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
All
I read the instructions above:
Description
There is an off by one error in the read logic for special channels, which causes the last memory to be read again...
For example, in a driver with 100 memories (0..99) and 5 special memories (100..105) the memory editor first retrieves memories 0 thru 99, and subsequently kicks off a low priority job to read the special memories, however rather than starting at 100 it begins at 99, thus reading the final non-special memory again...
This has no real consequence on the result other than being a bit confusing to developers when working on a driver, and obviously being unnecessary
Actions