aboutsummaryrefslogtreecommitdiff
path: root/test/functional/feature_block.py
diff options
context:
space:
mode:
authorWladimir J. van der Laan <laanwj@gmail.com>2018-09-17 13:32:47 +0200
committerWladimir J. van der Laan <laanwj@gmail.com>2018-09-17 13:33:05 +0200
commit72e358dca7d9f470e9e42e4b715a8edfc7b53bdb (patch)
tree9e2aa7a584b68281f72762add9d45f8f0590137a /test/functional/feature_block.py
parent3832c25f176753b7ddb724c26ee7543fb1e1819e (diff)
parentbe54f42e5f309ff332d74828ae294636d77fb8ea (diff)
downloadbitcoin-72e358dca7d9f470e9e42e4b715a8edfc7b53bdb.tar.xz
Merge #14227: integer division instead of implicit double conversion
be54f42e5f309ff332d74828ae294636d77fb8ea use integer division instead of double conversion and multiplication for computing amounts (Arvid Norberg) Pull request description: use integer division instead of double conversion and multiplication for computing amounts. This will most likely generate identical code. My main argument in favour of this change is one of purity, that we should not rely on implicit conversion from `CAmount` -> `double` and back again. Today this implicit conversion can happen because `CAmount` is just a typedef to `int64_t`. However, I envision a future where `CAmount` is a proper type that does not allow suspicious implicit conversions like these. Tree-SHA512: a70966623ac6e82410ac94d26cf44e2b7b7a4dbaa514d68ae1f0369aaee1bc2851d05a5e365291b005fe0941428e6139dc62bcfdd0b2f66720706fefe0eb92f1
Diffstat (limited to 'test/functional/feature_block.py')
0 files changed, 0 insertions, 0 deletions