fad6d4f952373690ef16ce27b0926c0ab762066a Remove not needed ArithToUint256 roundtrips in tests (MarcoFalke)
fa456ccb2287b2a1a4eb7224b424f12fe59302e9 Remove duplicate static_asserts (MarcoFalke)
Pull request description:
No need to go from `arith_uint256`->`uint256` when a `uint256` can be constructed right away.
ACKs for top commit:
laanwj:
Code review ACK fad6d4f952373690ef16ce27b0926c0ab762066a
Tree-SHA512: bea901ea5904bf61a0dadf7168c6b126f7e62ff1180d4aa72063c28930a01a8baa57ab0d324226bd4de72fb59559455c29c049d90061f888044198aae1426dcb
a4f4f89815c5aadff51a7a11e0d63caf5212345a Replace uint256 specific implementations of base_uint::GetHex() and base_uint::SetHex() with proper ones that don't depend on uint256 and replace template methods instantiations of base_uint with template class instantiation (Samer Afach)
Pull request description:
The current implementations of `SetHex()` and `GetHex()` in `base_uint` use `arith_uint256`'s implementations. Which means, any attempt to create anything other than `arith_uint256` (say `arith_uint512`) and using any of these functions (which is what I needed in my application) will just not work and will cause compilation errors (besides the immediate linking errors due to templates being in source files instantiated only for 256) because there's no viable conversion from `arith_uint256` and any of the other possible types. Besides that these function will yield wrong results even if the conversion is possible depending on the size. This is fixed in this PR.
ACKs for top commit:
laanwj:
re-ACK a4f4f89815c5aadff51a7a11e0d63caf5212345a
Tree-SHA512: 92a930fb7ddec5a5565deae2386f7d2d84645f9e8532f8d0c0178367ae081019b32eedcb59cc11028bac0cb15d9883228e016a466b1ee8fc3c6377b4df1d4180
aaaaad6ac95b402fe18d019d67897ced6b316ee0 scripted-diff: Bump copyright of files changed in 2019 (MarcoFalke)
Pull request description:
ACKs for top commit:
practicalswift:
ACK aaaaad6ac95b402fe18d019d67897ced6b316ee0
promag:
ACK aaaaad6ac95b402fe18d019d67897ced6b316ee0 🎉
fanquake:
ACK aaaaad6ac95b402fe18d019d67897ced6b316ee0 - going to merge this now because the year is over and conflicts are minimal.
Tree-SHA512: 58cb1f53bc4c1395b2766f36fabc7e2332e213780a802762fff0afd59468dad0c3265f553714d761c7a2c44ff90f7dc250f04458f4b2eb8eef8b94f8c9891321
084e17cebd424b8e8ced674bc810eef4e6ee5d3b Remove unused includes (practicalswift)
Pull request description:
As requested by MarcoFalke in https://github.com/bitcoin/bitcoin/pull/16273#issuecomment-521332089:
This PR removes unused includes.
Please note that in contrast to #16273 I'm limiting the scope to the trivial cases of pure removals (i.e. no includes added) to make reviewing easier.
I'm seeking "Concept ACK":s for this obviously non-urgent minor cleanup.
Rationale:
* Avoids unnecessary re-compiles in case of header changes.
* Makes reasoning about code dependencies easier.
* Reduces compile-time memory usage.
* Reduces compilation time.
* Warm fuzzy feeling of being lean :-)
ACKs for top commit:
ryanofsky:
Code review ACK 084e17cebd424b8e8ced674bc810eef4e6ee5d3b. PR only removes include lines and it still compiles. In the worst case someone might have to explicitly add an include later for something now included implicitly. But maybe some effort was taken to avoid this, and it wouldn't be a tragedy anyway.
Tree-SHA512: 89de56edc6ceea4696e9579bccff10c80080821685b9fb4e8c5ef593b6e43cf662f358788701bb09f84867693f66b2e4db035b92b522a0a775f50b7ecffd6a6d
cf4b0327ed92ca8a1533cdf6c2b0015fd9b56397 Use std::numeric_limits<UNSIGNED>::max()) instead of (UNSIGNED)-1 (practicalswift)
6b82fc59eb19004e54f910261a40d5e1b9e44b42 Use const in COutPoint class (Hennadii Stepanov)
Pull request description:
Refactoring:
- all cases of using `(uint32_t) -1` in `COutPoint` class are replaced with const;
- also all remaining instances of `(UNSIGNED)-1` transformed to `std::numeric_limits<UNSIGNED>::max()` (by @practicalswift).
Tree-SHA512: fc7fe9838b6e5136d8b97ea3d6f64c4aaa1215f4369832df432cab017396620bb6e30520a64180ceab6de222562ac11eab243a78dfa5a658ba018835a34caa19
2acd1d6716959b99e751cf85a7c47aaa383e937f Drop uint 256 not operator (Ben Woosley)
Pull request description:
All the other operators are integer or bitwise operations, and this is unused
apart from tests.
Note attempting to call `!` on `arith_uint256` results in a build error after this change:
```
test/arith_uint256_tests.cpp:201:17: error: invalid argument type 'const arith_uint256' to unary expression
BOOST_CHECK(!ZeroL);
```
Tree-SHA512: 5791b643f426dac9829e9499d678786f1ad294edb2d840879252a1b642bda55941632114f64048660a5991a984aeba49eeb5dfe64ba0a6275cbe7b1c049d7095
22b4aae02 [arith_uint256] Avoid unnecessary this-copy using prefix operator (Karl-Johan Alm)
Pull request description:
I noticed while profiling a related project that `operator-()` actually calls the `base_uint` constructor, which is because the postfix operator version of `operator++` (used in `operator-()`) creates a copy of `this` and returns it.
Tree-SHA512: d9a2665caa3d93f064cdeaf1c6fada101b9943bb53d93ccac6d9a0edac20279d2e921349e30239039c71e0a9629e45c29ec9f10d8d7499e936cdba6cb7c3c3eb
e5c6168 Fix instantiation and array accesses in class base_uint<BITS> (Pavlos Antoniou)
Tree-SHA512: e4d39510d776c5ae8814cd5fb5c5d183cd8da937e339bff95caff68a84492fbec68bf513c5a6267446a564d39093e0c7fc703c645b511caab80f7baf7955b804
Remove initialization from vector (as this is only used in the tests).
Also implement SetHex and GetHex in terms of uint256, to avoid
duplicate code as well as avoid endianness issues (as they
work in term of bytes).
- Methods that access the guts of arith_uint256 are removed,
as these are incompatible between endians. Use uint256 instead
- Serialization is no longer needed as arith_uint256's are never
read or written
- GetHash is never used on arith_uint256
