Add GetBlockIndex(const uint256& hash) for when the caller assumes that the block index exists for the given block hash. As suggested by @promag in #12782.
Rationale: Explicit is better than implicit. Especially for assumptions :-)
Heh you don't waste time do you?
Concept ACK.
Maybe add a comment in LookupBlockIndex about GetBlockIndex and vice-versa?
@promag Good point. Fixed! Please re-review :-)
429 | @@ -430,13 +430,26 @@ class CVerifyDB { 430 | /** Replay blocks that aren't fully applied to the database. */ 431 | bool ReplayBlocks(const CChainParams& params, CCoinsView* view); 432 | 433 | +// GetBlockIndex(...) should be used instead if the caller assumes that the
Maybe improve a bit:
/** Find and retrieve the block index for the given block hash.
* The caller must check if the block index is valid. If the block index
* always exists then use GetBlockIndex instead.
* Call with cs_main held.
*
* [@param](/bitcoin-bitcoin/contributor/param/)[in] hash The block hash
* [@return](/bitcoin-bitcoin/contributor/return/) The block index pointer if found, nullptr otherwise
* [@see](/bitcoin-bitcoin/contributor/see/) GetBlockIndex
*/
437 | AssertLockHeld(cs_main);
438 | BlockMap::const_iterator it = mapBlockIndex.find(hash);
439 | return it == mapBlockIndex.end() ? nullptr : it->second;
440 | }
441 |
442 | +// The caller knows if the block index exists for the given block hash.
/** Retrieve the block index for the given block hash.
* The block index must exists otherwise an assertion fails. If the block index
* can not exist then use LookupBlockIndex instead.
* Call with cs_main held.
*
* [@param](/bitcoin-bitcoin/contributor/param/)[in] hash The block hash
* [@return](/bitcoin-bitcoin/contributor/return/) The block index pointer
* [@see](/bitcoin-bitcoin/contributor/see/) LookupBlockIndex
*/
Alternative docblock.
@promag Much better! Thanks. Updated. Please re-review :-)
utACK 23f1760.
Nit, commit message could be shorter.
Why would we want this? It looks like just needless additional interfaces and code duplication for nothing more than an assert. NACK without justification.
@TheBlueMatt yes, nothing more than that. You probably prefer #12782.
Closing since lack of consensus ACK :-)
@TheBlueMatt A simple assert(…) was originally suggested: see PR #12782 :-)