Some developers clearly don't get this and have been posting
"improvements" that create clear vulnerabilities. It should
have been better explained in the code, since the design
is somewhat subtle and getting it right is important.
This patch changes the implementation from one that stores 16 2-bit integers
in one uint32_t's, to one that stores the first bit of 64 2-bit integers in
one uint64_t and the second bit in another. This allows for 450x faster
refreshing and 2.2x faster average speed.
Change the few occurrences of the deprecated `auto_ptr` to c++11 `unique_ptr`.
Silences the deprecation warnings.
Also add a missing `std::` for consistency.
Bitwise logic combined with `<` with undefined signedness will
potentially results in undefined behavior. Fix this by defining the type
as a c++11 typed enum.
Fixes#6017.
f135e3c qt: Add transaction hash to details window title (Wladimir J. van der Laan)
17a6a21 qt: Make it possible to show details for multiple transactions (Wladimir J. van der Laan)
7df9224 doc: Add note about new build/test requirements to release notes (Wladimir J. van der Laan)
2aacc72 build: update ax_cxx_compile_stdcxx to serial 4 (Wladimir J. van der Laan)
a398549 depends: use c++11 (Cory Fields)
67969af build: Enable C++11 build, require C++11 compiler (Wladimir J. van der Laan)
DumpBanList currently does this:
- with lock: take a copy of the banmap
- perform I/O (write out the banmap)
- with lock: mark the banmap non-dirty
If a new ban is added during the I/O operation, it may never be persisted to
disk.
Reorder operations so that the data to be persisted cannot be older than the
time at which the banmap was marked non-dirty.
I made a silly mistake in a database wrapper where keys
were sorted by char instead of uint8_t. As x86 char is signed
the sorting for the block index database was messed up, resulting
in a segfault due to missing records.
Add a test to catch:
- Wrong sorting
- Seeking errors
- Iteration result not complete
Disabling warnings can be tricky, because doing so can cause a different
compiler to create new warnings about unsupported disable flags. Also, some
warnings don't surface until they're paired with another warning (gcc). For
example, adding "-Wno-foo" won't cause any trouble, but if there's a legitimate
warning emitted, the "unknown option -Wno-foo" will show up as well.
Work around this in 2 ways:
1. When checking to see if -Wno-foo is supported, check for "-Wfoo" instead.
2. Enable -Werror while checking 1.
If "-Werror -Wfoo" compiles, "-Wno-foo" is almost guaranteed to be supported.
-Werror itself is also checked. If that fails to compile by itself, it likely
means that the user added a flag that adds a warning. In that case, -Werror
won't be used while checking, and the build may be extra noisy. The user would
need to fix the bad input flag.
Also, silence 2 more additional warnings that can show up post-c++11.
This was doing more harm than good. The original intention was to speed up
builds, since a PR's ccache results will be thrown away anyway.
However, each PR maintains its own cache, so disabling writes means that
subsequent pushes don't benefit from the fresh cache. This is significant when
(for example) many headers are touched in a PR, then the PR is updated. With
this change, the updated PR will take advantage of the cache generated during
the PR's previous build.
ActivateBestChain uses chainActive after releasing the lock; reorder operations
to move all access to synchronized object into existing LOCK(cs_main) block.
Puru