fix(search): use wxUIntPtr for m_currentSearch to fix Windows EC search - #39
Merged
got3nks merged 1 commit intoJun 9, 2026
Merged
Conversation
On Windows (LLP64), `long` is signed 32-bit but `wxUIntPtr` (the type of CSearchList::m_results keys and CSearchFile::m_searchID) is unsigned 64-bit. When an EC client starts a Local or Global ed2k search, `m_currentSearch = *searchID` stores 0xffffffff into a signed 32-bit long, overflowing to -1. The subsequent conversion to `wxUIntPtr` for `m_results[m_currentSearch]` (via `CSearchFile`'s ctor) sign-extends -1 to 0xFFFFFFFFFFFFFFFF, so the server reply lands in `m_results[0xFFFFFFFFFFFFFFFF]`. Lookups in `Get_EC_Response_Search_Results` use the literal `0xffffffff` which is unsigned int -> wxUIntPtr zero-extension to 0x00000000FFFFFFFF. Different key. Items are unreachable. Net effect: EC-driven ed2k searches return 0 results on Windows even though the daemon-side server response was received and the items were added to the searchlist (amule-project#31). Linux x64 (LP64) is unaffected: `long` is 64-bit there, so the overflow doesn't happen and the bit pattern matches the lookup key. Kad searches were also unaffected: Kad results go through `KademliaSearchKeyword(uint32_t searchID, ...)` which writes the result via `CSearchFile`'s `wxUIntPtr searchID` ctor parameter directly -- uint32_t zero-extends to wxUIntPtr cleanly, no signed long detour. Fix: change `m_currentSearch` to `wxUIntPtr`, matching the type of every other place the value flows (CSearchFile::m_searchID, ResultMap keys, GetSearchResults/RemoveResults parameters). The existing `-1` sentinel assignments still work (unsigned -1 wraps to 0xFFFFFFFFFFFFFFFF on both platforms, no code paths compare against -1 explicitly).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the Windows-specific 0-results bug @ngosang reported on #31 — EC clients (amuleweb / amulecmd) returned 0 ed2k Local/Global results on Windows even though the daemon side correctly received the server's reply.
Root cause: LLP64 vs LP64
CSearchList::m_currentSearchis declaredlong(SearchList.h:217) but every other place this value flows useswxUIntPtr(CSearchFile::m_searchID,std::map<wxUIntPtr, CSearchResultList> m_results,GetSearchResults/RemoveResultsparameters).On Windows (LLP64),
longis signed 32-bit andwxUIntPtris unsigned 64-bit. The EC search-start path does:m_currentSearch = *searchIDwhere*searchID = 0xffffffff(uint32). Assignment to signedlongoverflows to-1.AddToList(new CSearchFile(..., m_currentSearch, ...))—m_currentSearch(long = int32 = -1) implicitly converts towxUIntPtr(uint64) via sign extension to0xFFFFFFFFFFFFFFFF.m_results[0xFFFFFFFFFFFFFFFF].But
Get_EC_Response_Search_Resultslooks upGetSearchResults(0xffffffff)— the literal isunsigned int, which zero-extends to wxUIntPtr0x00000000FFFFFFFF. Different key.m_results.find(...)returns empty. amuleweb / amulecmd see 0 results.Linux x64 (LP64):
longis 64-bit, no overflow, the bit pattern matches the lookup. Bug invisible.Why Kad searches still worked on Windows
Kad results path bypasses
m_currentSearch:KademliaSearchKeyword(uint32_t searchID, ...)writes the result viaCSearchFile'swxUIntPtr searchIDctor parameter directly, so theuint32_t -> wxUIntPtrzero-extension matches the lookup. The corrupted value ofm_currentSearchis never read for Kad.Fix
One line — declare
m_currentSearchaswxUIntPtrinstead oflong:This matches the type of every other place the value flows, eliminating the signed-vs-unsigned width mismatch.
Verification on Windows ARM64 VM
Pre-fix
amulecmd search local ubuntu→resultsreports 0 hits despite the daemon having received and parsed 153 results from the server (confirmed via diagnostic logging inProcessSearchAnswer).Post-fix:
search local ubuntu→ 151 results returned.search global ubuntu→ 272 results. Both Local and Global now work via EC on Windows.Backward compat
Linux x64: unchanged.
longwas already 64-bit, the bit pattern was already correct. New type is the same bit width.Windows: fixes the bug, no behavior change for any non-buggy case.
No protocol change, no client-side change.