Skip to content

Fix cppcheck [useInitializationList] warnings - #191

Merged
mrjimenez merged 1 commit into
amule-project:masterfrom
sc0w:PR_cppcheck_useInitializationList
Jun 7, 2026
Merged

Fix cppcheck [useInitializationList] warnings#191
mrjimenez merged 1 commit into
amule-project:masterfrom
sc0w:PR_cppcheck_useInitializationList

Conversation

@sc0w

@sc0w sc0w commented May 27, 2020

Copy link
Copy Markdown
Member

No description provided.

@gonosztopi gonosztopi left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment on #190

@sc0w

sc0w commented May 29, 2020

Copy link
Copy Markdown
Member Author

I don't understand you, this PR isn't related to #190, please review here this PR.

@Stoatwblr Stoatwblr mentioned this pull request Jun 7, 2020
@gonosztopi

Copy link
Copy Markdown
Member

In short, the problem is: you're fixing warnings not code.

Some examples:

  • in src/FileLock.h you move the initialization of hd into the initialization list of the constructor. You didn't notice that it was a false positive from cppcheck, because hd is of type HANDLE which actually is a void *. Thus the change doesn't come with any benefit but reduced readability.

  • still staying at src/FileLock.h, there is a #if block starting inside a function and spanning through to the end of the file. That's a really really bad thing and should have been fixed first.

  • in src/IP2Country.cpp you move m_DataBaseName but not m_DataBasePath which has the same type (wxString). I admit it has a more complex initializer, but that can be simplified to allow it going, too.

  • moving POD-types into the initialization list doesn't do any benefit (nor harm, to be honest). I guess the warnings you got for src/webserver/src/WebSocket.cpp are because cppcheck didn't know what uint32 was.

  • and last but not least, I miss the style from your patch. You pick some variables (sometimes seemingly randomly) to move and leave the others. With the exceptions being src/utils/wxCas/src/onlinesig.cpp and the ones where there were only one member to initialize...

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.

@mrjimenez
mrjimenez marked this pull request as draft June 1, 2026 23:13
@irwir

irwir commented Jun 7, 2026

Copy link
Copy Markdown

This PR should be too old for the current code.
It is free to download cppcheck and run its GUI.
For me, there were a few useful findings, including real bugs.
Expect a few false positives too, but with small experience those could be easily discarded.

@mrjimenez
mrjimenez force-pushed the PR_cppcheck_useInitializationList branch from 59e38ec to 1a457d2 Compare June 7, 2026 16:38
@mrjimenez

Copy link
Copy Markdown
Contributor

Thanks for this PR — the core idea is correct and worth landing. I rebased it onto the current master and resolved the conflicts by hand. Here's what changed:

Applied as-is (clean auto-merge):

  • src/AsyncDNS.cppm_ipName moved to init list, preserving the thread-safety comment
  • src/GapList.hm_it in const_iterator
  • src/Tag.cppm_Name in both CTag(wxString) and CTag(CTag&)
  • src/TextClient.cppnHash in SearchFile
  • src/utils/wxCas/src/onlinesig.cpp — all 7 members (this one was the cleanest in the original PR)

Applied with fixes (conflict resolution):

  • src/CanceledFileList.cpp — moved to init list but removed wxT(), which was retired tree-wide in the meantime
  • src/Friend.cpp — moved m_UserHash to init list; kept m_HasFriendSlot = false in the body (that field was added after this PR was opened, in GUI: friend slot keeps disabling itself #282)
  • src/webserver/src/WebSocket.cpp — kept the init-list entries, but preserved the [4096+1] allocation and its comment (added in Off-by-one heap write in CWebSocket::OnReceive #873 to fix an off-by-one); removed the now-redundant body assignments

Dropped intentionally:

  • src/FileLock.hHANDLE is void* (a POD type), so cppcheck's warning here is a false positive; moving a multi-line CreateFileA(...) call into the init list buys nothing and hurts readability
  • src/IP2Country.cpp — this file was completely rewritten to use libmaxminddb instead of libGeoIP; the GeoIP.dat initializer no longer exists

@mrjimenez
mrjimenez marked this pull request as ready for review June 7, 2026 16:53
@mrjimenez

Copy link
Copy Markdown
Contributor

@got3nks , what do you think? Harmless?

The FileLock.h #if inside a function issue can be handled elsewhere.

@got3nks

got3nks commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

Looks safe to land — sanity-checked your four decisions against current master and they all hold up:

  • Applied as-isAsyncDNS, GapList, Tag, TextClient, onlinesig: assignment-in-body → init-list is purely syntactic, no runtime effect.
  • Applied with fixesCanceledFileList (drop wxT()), Friend (keep m_HasFriendSlot = false from GUI: friend slot keeps disabling itself #282), WebSocket (preserve [4096+1] from Off-by-one heap write in CWebSocket::OnReceive #873): all correct against the current files; the surrounding code you kept is the bit that actually matters.
  • DroppedFileLock.h's HANDLE is POD void* so cppcheck's warning is a false positive, and IP2Country.cpp is now libmaxminddb-based with no GeoIP.dat initializer to touch. Both N/A.

Agree on FileLock.h — the per-platform #if-split inside the class body (two constructors, two destructors, two private: sections with different members) is its own much bigger refactor target and shouldn't bottle this PR.

Harmless and worth landing.

@mrjimenez
mrjimenez merged commit d9c055d into amule-project:master Jun 7, 2026
7 checks passed
mrjimenez pushed a commit to mrjimenez/amule that referenced this pull request Jun 17, 2026
…t-defensive-rewind

fix(aich): true linear-scan fallback when LoadHashSet cache offset is stale
mrjimenez pushed a commit to mrjimenez/amule that referenced this pull request Jun 17, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants