Fix logic used to determine if Aleth should request dao fork block header from potential peer#5539
Fix logic used to determine if Aleth should request dao fork block header from potential peer#5539
Conversation
We need this check because all hard fork chain parameter fields are initialized to c_infiniteBlockNumber to indicate not set. Fork block chain params members are initialized to
Also move BlockchainSync constants inside of existing anonymous namespace.
halfalicious
changed the title
Codecov Report
@@ Coverage Diff @@
## master #5539 +/- ##
==========================================
- Coverage 61.9% 61.88% -0.03%
==========================================
Files 344 344
Lines 28757 28769 +12
Branches 3267 3269 +2
==========================================
+ Hits 17803 17804 +1
- Misses 9784 9795 +11
Partials 1170 1170 |
libethcore/ChainOperationParams.h
Outdated
| }; | ||
|
|
||
| static constexpr int64_t c_infiniteBlockNumer = std::numeric_limits<int64_t>::max(); | ||
| static constexpr int64_t c_infiniteBlockNumber = std::numeric_limits<int64_t>::max(); |
There was a problem hiding this comment.
The static is redundant for constexpr.
There was a problem hiding this comment.
I thought that static and constexpr are orthogonal concepts? I agree that static doesn't make sense here (regardless of the constexpr) since this is a header file and c_infiniteBlockNumber is defined outside of a class - from what I understand, static when used this way limits the scope of the variable to the translation unit which means that each cpp file which includes the header will have a separate instance of c_infiniteBlockNumber (though each instance will have the same value) which seems unnecessary.
There was a problem hiding this comment.
I'm also confused now. On the language level that might be true. But also constexpr implies inline and inline implies static.
I check than in practice the constexpr symbols are not exported.
libethereum/BlockChainSync.cpp
Outdated
| namespace // Helper functions. | ||
| { | ||
|
|
||
| unsigned constexpr c_maxPeerUknownNewBlocks = 1024; /// Max number of unknown new blocks peer can give us |
There was a problem hiding this comment.
Pedantic mode: should be constexpr unsigned.
There was a problem hiding this comment.
Why do we put constexpr before the type but const after the type?
4 participants
Fix #5271
Update the logic which Aleth uses to determine if it should request the DAO fork block header from a peer before starting a sync based on the value of the
daoHardForkchain configuration parameter. Aleth needs to check for 0 orc_infiniteBlockNumber(rather than just 0) because Aleth initializes thedaoHardForkconfiguration parameter toc_infiniteBlockNumberby default.The impact of these changes is that one doesn't have to explicitly specify
daoHardFork= 0x0 in anyconfig.jsonthat they wish to use with Aleth.