on rare occasions, rand() was returning duped values, causing duplicate
transactions.
BuildMerkleTree happily used these, but CPartialMerkleTree caught them and
returned a null merkle root.
Rather than taking changes with rand(), use the loop counter to guarantee
unique values.
At sipa's request, also remove the remaining uses of rand().
6bd0dc2 arith_uint256: remove initialization from byte vector (Wladimir J. van der Laan)
30007fd Remove now-unused methods from arith_uint256 and base_uint (Wladimir J. van der Laan)
edc7204 Remove arith_uint160 (Wladimir J. van der Laan)
dba2e91 Add tests for new uint256 (Wladimir J. van der Laan)
92cdb1a Add conversion functions arith_uint256<->uint_256 (Wladimir J. van der Laan)
bfc6070 uint256->arith_uint256 blob256->uint256 (Wladimir J. van der Laan)
734f85c Use arith_uint256 where necessary (Wladimir J. van der Laan)
34cdc41 String conversions uint256 -> uint256S (Wladimir J. van der Laan)
2eae315 Replace uint256(1) with static constant (Wladimir J. van der Laan)
8076585 Replace GetLow64 with GetCheapHash (Wladimir J. van der Laan)
4f15249 Replace direct use of 0 with SetNull and IsNull (Wladimir J. van der Laan)
5d3064b Temporarily add SetNull/IsNull/GetCheapHash to base_uint (Wladimir J. van der Laan)
Remove initialization from vector (as this is only used in the tests).
Also implement SetHex and GetHex in terms of uint256, to avoid
duplicate code as well as avoid endianness issues (as they
work in term of bytes).
- Methods that access the guts of arith_uint256 are removed,
as these are incompatible between endians. Use uint256 instead
- Serialization is no longer needed as arith_uint256's are never
read or written
- GetHash is never used on arith_uint256
If uint256() constructor takes a string, uint256(0) will become
dangerous when uint256 does not take integers anymore (it will go
through std::string(const char*) making a NULL string, and the explicit
keyword is no help).
SignatureHash and its test function SignatureHashOld
return uint256(1) as a special error signaling value.
Return a local static constant with the same value instead.
12d927a RPC test for immature balance (Jonas Schnelli)
8024d67 Add immature balances to getwalletinfo. (Gregory Maxwell)
d44c545 Add unconfirmedbalance field to getwalletinfo (azeteki)
4caad26 depends: bump cctools to a custom version with less deps (Cory Fields)
46f54bf build: osx builders no longer need 32bit compiler support (Cory Fields)
4fe6c3c depends: major upgrade to darwin toolchain (Cory Fields)
ec90c97 depends: osx: fix qt5 build against 10.10 sdk (Cory Fields)
With the splashscreen being able to be closed it is possible to
shutdown during the lengthy verifyDB method. (Takes about a minute
on my machine). This change allows us to shutdown much sooner.
Github-Pull: #5557
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
1b178a7 Bugfix: ConnectBlock: In case the genesis block gets in with fJustCheck, behave correctly (Luke Dashjr)
228d238 Make CCoinsViewCache's copy constructor private (Luke Dashjr)
Broken hash logic caused all depends on some platforms (osx at least) to end up
with the same build-id. Without this fix, nothing will be rebuilt when recipes
or dependencies change.
Cory Fields