The BufferPool::writeHex() method takes a string-pointer, we add an int
max-number-of-chars to be parsed on that string.
This allows us to not just stop at the first non-hex char, but also
after a set number of characters.
This effectively allows us to use non-zere-terminated strings as
argument too.
This adds endsWith() and an extra startsWith() overload.
We also added tests for the case when either the argument or the object
are empty and specify the behavior. I copied the behavior of QString.
See unit tests that specify the behavior with empties.
As we moved most of the creation of a BufferPool to be via the
Streaming::pool() method, which uses a thread-local, it makes sense
to start cleaning up the design and make it more modern C++.
The above mentioned method would return a reference and you'd see
loads of places use `auto &pool =` which is less than ideal.
As the number of places where we actually instantiate a BufferPool
goes down, the usage of some sort of smart pointer makes more sense.
This now makes all APIs use BufferPool be wrapped in a shared_ptr.
The unit tests testing base58 encoding were using univalue JSON
parsing, since we deprecatd univalue to be a hub-private lib
this has now been ported to Qts JSON parser.
Which also makes the clunky cmake hack nice to replace with the
QRC files concept.
As I was in there anyway, the base58 methods being global scope
C-style methods has now been fixed by putting them in a namespace.
As this is not actually used outside of the Hub, it really makes
more sense to make this testing part of the hub testing.
Also makes it easier to compile.
We already had in place the blockSizeAcceptLimit as the limit
on messages, which is now the only limit.
In practice this means when the operator sets the maximum mining
size that we adjust the blockSizeAcceptLimit, if they only set the
blockSizeAcceptLimit, we use that (plus a margin) to limit messages
both on the p2p layer and on the RPC (JSON) layer we change the
limit to be twice the blockSizeAcceptLimit (copied those numbers
from BCHN).
This means that for apps like 'pos' no longer link against libSSL
The streams no longer zero-after-free, there are no secrets transported
in datastreams so this is useless and avoids linking in one OpenSSL
call.
The insecure_rand() method depended on the openssl code to seed it with
randomness. Now replaced with a proven current-time-milliseconds.
This is enough in those cases because it was always meant to be an
insecure random.
The 'server' library has always been a catch-all and
ideally only the hub links it in (far future goal).
In line with this I move a list of files out of server
into the utils lib.
I choose 'utils' because all these are plain old data
objects that many crypto apps will find useful.
now in utils/primitives/
* CScript
* CPubKey
* CTransaction
* CBlock
* FastTransaction
* FastBlock
* CScript
streams.h is now in utils/streaming/
hash.h is now in utils/
As boost testlib is extremely IDE unfriendly, as well as human
unfriendly with lots of macros for basic C++ functions (like methods!!)
this is better for me.
But the real reason is that its just unstable. I get double deletes
on some releases of boost and I'm missing plain features that all
other test frameworks have.
For instance a QCOMPARE shows what is expected vs what we got. Boost
just fails.
In QTestLib I can mark a test as "expect fail" an idea that boost
tried and failed (can easily create false positives).
tomFlowee
TomZ