Bug #9401

Memory editor reads last memory twice

Added by Kosta A. about 1 month ago. Updated about 1 month ago.

Status:Closed Start date:09/28/2021
Priority:Low Due date:
Assignee:Kosta A. % Done:


Target version:-
Chirp Version:daily Platform:All
Model affected:(All models)


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

Associated revisions

Revision 3581:18c79677e9e2
Added by Kosta A. about 1 month ago

  1. Parent d156d3a46b7e6cbce985dc14186f0e07b5d3016b
    Prevent memory editor from always loading last memory in memory range twice. Fixes #9401


Updated by Kosta A. about 1 month ago

  • Status changed from New to Resolved

In the orginal description i described the issue as pertaining to special memories, this is technically not accurate, as the issue refers to the memories loaded outside of the specified memory range...

The memory editor first loads the lo..hi+1 memories (where lo and hi are computed by the UI), then loads the hi..max memories (where max is computed from the driver memory bounds), thus loading the hi'th memory twice.

Either way a patch has been sent to the mailing list.

Updated by Kosta A. about 1 month ago

  • Assignee set to Kosta A.

Updated by Kosta A. about 1 month ago

  • Status changed from Resolved to Closed

Applied in changeset 18c79677e9e2.

Also available in: Atom PDF