Fix cppcheck [useInitializationList] warnings - #191
Conversation
|
I don't understand you, this PR isn't related to #190, please review here this PR. |
|
In short, the problem is: you're fixing warnings not code. Some examples:
If you're already using cppcheck, there are more severe issues in the code.... (just a hint). If I were you I would certainly open a branch and commit there all the changes required by cppcheck, all the changes that were made on the way to fix bugs you encounter meanwhile. And maybe create a configuration file for cppcheck to prevent false positives. And, while we're already at it, use meaningful commit messages, describing what and why you change. |
|
This PR should be too old for the current code. |
59e38ec to
1a457d2
Compare
|
Thanks for this PR — the core idea is correct and worth landing. I rebased it onto the current Applied as-is (clean auto-merge):
Applied with fixes (conflict resolution):
Dropped intentionally:
|
|
@got3nks , what do you think? Harmless? The |
|
Looks safe to land — sanity-checked your four decisions against current master and they all hold up:
Agree on Harmless and worth landing. |
…t-defensive-rewind fix(aich): true linear-scan fallback when LoadHashSet cache offset is stale
PR amule-project#191 added a defensive rewind so LoadHashSet finds the right entry even when the cached offset is stale (known2.met modified externally between cache load and the request). The rewind worked but didn't update the cache: every subsequent LoadHashSet for the same stale root hash kept paying the seek-miss + full linear scan, instead of the O(1) cache hit the cache exists to provide. The cache only self-cleared on daemon restart, on CEOFException-driven truncation, or after an orphan-prune rewrite in CAICHSyncTask -- none of which fire just because a single entry's offset went stale. When the rewind succeeds, the linear scan has just found the right position for the root hash. Stamp it back into s_rootHashCache so future lookups for the same hash go straight there. Capture the entry's start position pre-read (entryStartPos) so we have the exact offset of the root hash, matching the value LoadRootHashCacheLocked and SaveHashSet write into the cache.
No description provided.