Jef,
I'm working though some of the changes you recommended and I'm looking for advice.
1. Fingerprint optimized download. The current logic only works when the DC's logbook buffer hasn't wrapped and will likely fail with a segfault when not the case. I have to treat the logbook like a ring buffer buffer and maybe I have to treat the profile data like ring buffer too. The logbook is small enough that optimizing its download makes less sense but optimizing the profile data would. It would mean more complicated logic and potentially downloading two segments if the profile data has wrapped. I'd create a buffer the size of DC memory and write the profile data in the proper areas to make the logic easier.
2. Foreach function size. You seem to want the read logic in the foreach function. If I put it all in-line, including the progress updates, logic to locate the fingerprint, the logic to determine which profile data to read it's going to be a very large function. It seems that keeping it seperate would make it much more readable. With those functions outside foreach() is 70 lines. You proposed version which is lacking many lines of code is 140 lines and
3. I'm concerned about the performance cost of using ring-buffer logic for profile data, although it solves existing bugs. The Cochran's profile data is not stored in blocks, it's a byte stream in which two or three bytes describes a second's worth of most data. Some data, like NDL, deco stop time and dive events are spread across many bytes and require reading ahead. As a result the code would be calling ring buffer_increment a lot, samples are every second, so a 1 hour dive would require over 11,000 calls to ring buffer_increment. I could add some logic to workaround that, it might not be too bad.