Credit to Crypt-iQ for finding and reporting the UBSan implicit-integer-sign-change issue and to vasild for the original review suggestion in #19590#pullrequestreview-455788826.
Closes #19678.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
1463 | - if (g_recent_confirmed_transactions->contains(inv.hash)) return true; 1464 | + LOCK(g_cs_orphans); 1465 | + if (!inv.IsMsgWtx() && mapOrphanTransactions.count(inv.hash)) { 1466 | + return true; 1467 | + } else if (inv.IsMsgWtx() && g_orphans_by_wtxid.count(inv.hash)) { 1468 | + return true;
nit: this was the code before, but since you are re-indenting/modifying it:
if (A) {
C;
} else if (B) {
C;
}
is the same as
if (A || B) {
C;
}
Yes, I deliberately did not touch it to keep the concepts separate.
430 | @@ -431,12 +431,20 @@ class CInv 431 | std::string ToString() const; 432 | 433 | // Single-message helper methods 434 | - bool IsMsgTx() const { return type == MSG_TX; } 435 | - bool IsMsgWtx() const { return type == MSG_WTX; } 436 | + bool IsUndefined() const { return type == UNDEFINED; } 437 | + bool IsMsgTx() const { return type == MSG_TX; } 438 | + bool IsMsgBlk() const { return type == MSG_BLOCK; }
nit: maybe use "Block" to be in line with the surrounding code, e.g. LookupBlockIndex(), MSG_BLOCK which uses the full word. "Blk" looks like "bulk" to me rather than "block".
Yes, I thought about this, but that would make the methods names quite a bit longer, and ISTM "blk" is an established abbreviation for "block", e.g. the filenames in ~/.bitcoin/blocks, and in the codebase git grep -i blk. Let's see what other reviewers say before changing (that change is actually in #19610, which needs to go in before this PR).
2804 | - inv.type = State(pfrom.GetId())->fWantsCmpctWitness ? MSG_WITNESS_BLOCK : MSG_BLOCK; 2805 | - inv.hash = req.blockhash; 2806 | - pfrom.vRecvGetData.push_back(inv); 2807 | + 2808 | + uint32_t inv_type{State(pfrom.GetId())->fWantsCmpctWitness ? MSG_WITNESS_BLOCK : MSG_BLOCK}; 2809 | + pfrom.vRecvGetData.emplace_back(CInv(inv_type, req.blockhash));
This call to emplace_back() will create a CInv temporary, copy-construct the object in the vector from the temporary and then destroy the temporary. Whereas emplace_back(inv_type, req.blockhash) would directly construct the object in the vector with the supplied arguments.
Good point, thank you! Done.
418 | @@ -419,6 +419,8 @@ enum GetDataMsg : uint32_t { 419 | /** inv message data */ 420 | class CInv 421 | { 422 | +private: 423 | + uint32_t type;
nit: maybe also rename it to m_type
It is indeed the preferred style for new code, but here it seems like a noisy change for little gain that would make the methods in the class longer and less readable. Also, the companion class member variable hash would also need to be changed. Holding off for now unless other reviewers think they are both worth changing.
447 | @@ -446,8 +448,8 @@ class CInv 448 | bool IsMsgBlkOrMsgWitnessBlk() const { return type == MSG_BLOCK || type == MSG_WITNESS_BLOCK; } 449 | bool IsGenBlkMsg() const { return type == MSG_BLOCK || type == MSG_FILTERED_BLOCK || type == MSG_CMPCT_BLOCK || type == MSG_WITNESS_BLOCK; } 450 | 451 | - uint32_t type; 452 | uint256 hash; 453 | + void SetTypeBitwiseOr(uint32_t flags) { type |= flags; }
Does it make sense to do some sanity checking of the supplied flags here?
I'm looking at removing this completely (per #19596 (review)).
Removed unused nFetchFlags from TX and INV net processing in ProcessMessages().
Tried to re-open this PR with an updated version, but apparently after a rebase/force-push on a closed PR, GitHub requires a new PR to be opened.