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.
Previous behavior with IsFinalTx() being an IsStandard() rule was rather
confusing and interferred with testing of protocols that depended on
nLockTime.
Otherwise, if CCoinsViewCache::ModifyCoins throws an exception in between
setting hasModifier and constructing the CCoinsModifier, the cache ends up
in an inconsistent state, resulting in an assert failure in the next
modification.
Bug discovered by Wladimir J. van der Laan.
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.
It is easily confused with CCoinsViewCache(CCoinsView*), which creates a sub-cache, but instead of creating a sub-cache, the copy constructor would copy the original and use that original's base, defeating the intended isolation.
