Use std::unique_ptr for handling work items.
This makes the code more RAII and, as mentioned in the comment, is what
I planned when I wrote the code in the first place.
08d7b56 util: switch LogPrint and error to variadic templates (Wladimir J. van der Laan)
9eaa0af tinyformat: force USE_VARIADIC_TEMPLATES (Wladimir J. van der Laan)
* CAddrDB modified so that when de-serialization code throws an exception Addrman is reset to a clean state
* CAddrDB modified to make unit tests possible
* Regression test created to ensure bug is fixed
* StartNode modifed to clear adrman if CAddrDB::Read returns an error code.
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.
Wladimir J. van der Laan