Any projects which want to use Hush code from now on will need to be licensed as
GPLv3 or we will send the lawyers: https://www.softwarefreedom.org/
Notably, Komodo (KMD) is licensed as GPLv2 and is no longer compatible to receive
code changes, without causing legal issues. MIT projects, such as Zcash, also cannot pull
in changes from the Hush Full Node without permission from The Hush Developers,
which may in some circumstances grant an MIT license on a case-by-case basis.
Use misc methods of avoiding unnecesary header includes.
Replace int typedefs with int##_t from stdint.h.
Replace PRI64[xdu] with PRI[xdu]64 from inttypes.h.
Normalize QT_VERSION ifs where possible.
Resolve some indirect dependencies as direct ones.
Remove extern declarations from .cpp files.
class template base_uint had its own private lookup table.
This is saving 256 bytes per instantiation.
The result is not spectacular as bitcoin-qt has only shrinked of
about 1Kb but it is still valid improvement.
Also, I have replaced a for loop with a memset() call.
Made CBigNum::SetHex() use the new HexDigit() function.
Signed-off-by: Olivier Langlois <olivier@olivierlanglois.net>
Every block index entry currently requires a separately-allocated
CBigNum. By replacing them with uint256, it's just 32 bytes extra
in CBlockIndex itself.
This should save us a few megabytes in RAM, and less allocation
overhead.
Since the minimum signed integer cannot be represented as positive so long as its type is signed, and it's not well-defined what happens if you make it unsigned before negating it, we instead increment the negative integer by 1, convert it, then increment the (now positive) unsigned integer by 1 to compensate
As noticed by sipa (Pieter Wuille), this can happen when CBigNum::setint64() is
called with an integer value of INT64_MIN (-2^63).
When compiled with -ftrapv, the program would crash. Otherwise, it would
execute an undefined operation (although in practice, usually the correct one).
CBigNum::setint64() does 'n <<= 8', where n is of type "long long".
This leads to shifting onto and past the sign bit, which is undefined
behavior in C++11 and can cause problems in the future.
C++ STL ::size() generally returns unsigned, which implies that "int idx"
style of loop variable will generate a signed-vs-unsigned comparison warning
when testing the loop exit condition "idx < blah.size()"
Update areas of the bitcoin code where loop variables may be more properly and
correctly defined as unsigned.
In ISO C++, the signedness of 'char' is undefined. On some platforms (e.g.
ARM), 'char' is an unsigned type, but some of the code relies on 'char' being
signed (as it is on x86). This is indicated by compiler warnings like this:
bignum.h: In constructor 'CBigNum::CBigNum(char)':
bignum.h:81:59: warning: comparison is always true due to limited range of data type [-Wtype-limits]
util.cpp: In function 'bool IsHex(const string&)':
util.cpp:427:28: warning: comparison is always false due to limited range of data type [-Wtype-limits]
In particular, IsHex erroneously returned true regardless of the input
characters, as long as the length of the string was a positive multiple of 2.
Note: For testing, it's possible using GCC to force char to be unsigned by
adding the -funsigned-char parameter to xCXXFLAGS.
When OpenSSL's BN_bn2mpi is passed a buffer of size 4, valgrind
reports reading/writing one byte past it. I am unable to find
evidence of this behaviour in BN_bn2mpi's source code, so it may
be a spurious warning. However, this change is harmless, as only
the bignum with value 0 results in an mpi serialization of size 4.
Duke Leto
Jack Grigg