-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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.
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
@@ -63,7 +63,7 @@ class PrecompiledContract | |||
u256 m_startingBlock = 0; | |||
}; | |||
|
|||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The static
is redundant for constexpr
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -52,6 +30,10 @@ std::ostream& dev::eth::operator<<(std::ostream& _out, SyncStatus const& _sync) | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pedantic mode: should be constexpr unsigned
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we put constexpr
before the type but const
after the type?
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
daoHardFork
chain configuration parameter. Aleth needs to check for 0 orc_infiniteBlockNumber
(rather than just 0) because Aleth initializes thedaoHardFork
configuration parameter toc_infiniteBlockNumber
by default.The impact of these changes is that one doesn't have to explicitly specify
daoHardFork
= 0x0 in anyconfig.json
that they wish to use with Aleth.